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the  development/acquisition  process  and  (2)  the  lack  of  a  comprehensive 
set  of  training  analysis  tools  which  are  appropriate  for  the  early  phases 
of  design.  The  ETES  will  have  four  major  components;  a  System  Descrip¬ 
tion  Technology,  training  estimation  aids  and  procedures,  human  perfor¬ 
mance  simulation  models,  and  a  users  guide. 

The  System  Description  Technology  (SDT)  will  be  an  automated  tool 
for  describing  actual  and  projected  system  elements,  including  functional 
requirements,  design  concepts,  tasks,  skills,  training  program  elements 
and  their  associated  resources;  for  storing  the  above  information;  for 
changing  and  updating  this  information;  and  for  transmitting  the  infor¬ 
mation  among  all  of  the  participants  in  the  acquisition  process. 

The  training  estimation  aids  and  procedures  will  be  specifically 
designed  for  early  training  estimation.  They  will  include  procedures 
(automated  whenever  possible)  for  (1)  identifying  comparable  equipments, 
(2)  generating  and  modifying  tasks,  (3)  generating  and  modifying  courses, 
(4)  selecting  and  assigning  tasks  to  training  settings  and  methods,  (5) 
determining  the  number  of  personnel  to  be  trained,  (6)  determining 
training  resources,  and  (7)  developing  training  ccst  measures. 

The  human  performance  -  system  performance  simulation  models  will 
be  used  to  relate  human  task  performance  to  system  performance.  The 
simulation  models  will  provide  the  capability  for  trading  off  training- 
related  system  elements  with  other  system  elements. 

The  User's  Guide  will  provide  a  detailed,  step-by-step-  handbook 
describing  the  use  of  the  other  three  tools  to  assess  early  training 
requirements. 

The  first  year  of  the  study  concentrated  on  the  development  of 
the  SDT,  the  most  important  component  of  ETES.  The  SDT  will  provide  a 
data  base  management  tool  which  will  be  capable  of  describing  most  of  the 
major  elements  of  an  emerging  system.  As  such,  the  SDT  will  provide  an 
important  data  base  management  capability  that  has  wide  ranging  appli¬ 
cability,  far  beyond  training-related  issues. 

^is  yearly  report  outlines  specifications  for  the  SDT  development, 
provides  a  description  of  the  physical  and  operational  features  of 
a  prototype  SDT  concept,  and  describes  the  analytical  procedures  under¬ 
lying  the  development  of  this  concept. 
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PREFACE 


This  paper  is  the  first  yearly  report  for  the  Early  Training 
Estimation  System  (ETES)  development  project  (Contract  No. 
MDA-903-80-C-0525) .  The  report  is  divided  into  four 
sections.  Section  1  provides  an  overview  of  the  report,  the 
ETES  study  coftiponents,  study  tasks,  and  the  major  activities 
that  were  conducted  under  these  tasks  during  the  first  year 
of  the  study.  The  next  three  chapters  describe  the  System 
Description  Technology,  the  most  important  component  of 
ETES.  Section  2  presents  a  set  of  detailed  specifications 
for  the  information  elements  which  must  be  described  by  the 
SDT.  Section  3  describes  the  results  of  an  evaluation  of 
current  automated  tools  which  were  considered  for 
application  in  the  SDT.  Section  4  presents  a  detailed 
description  of  the  physical  and  operational  characteristics 
of  the  SDT. 

A  number  of  different  analyses  and  reviews  were  conducted 
during  the  first  year  of  ths  study  in  support  of  the  SDT 
development.  These  analyses  are  described  in  a  series  of 
appendices.  Appendix  A  presents  the  results  of  a  detailed 
review  of  existing  Army  acquisition  procedures  and  practices 
and  their  implications  for  ETES.  Appendix  B  describes  some 
examples  of  the  types  of  information  which  are  likely  to  be 
output  from  the  SDT.  Appendix  C  presents  the  results  of  a 
review  of  psychological  research  related  to  design  and  its 
implications  for  the  SDT.  Appendix  D  reviews  psychological 
research  related  to  human  comDuter  interaction,  an  area  of 
research  closely  related  to  the  automated  SDT. 
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SECTION  1  -  SUMMARY 


This  section  summarizes  the  activities  and  analyses 
conducted  during  the  first  year  of  the  Early  Training 
Estimation  System  (ETES)  development  project.  The  section 
is  divided  into  five  subsections.  Subsection  1.1  reviews 
the  general  trends  which  are  placing  heavier  and  heavier 
demands  on  training  development.  Subsection  1.2  describes 
the  specific  problems  and  deficiencies  in  existing  Army 
practices  which  led  to  the  initiation  of  the  ETES  project. 
Subsection  1.3  presents  an  overview  of  the  four  components 
of  ETES.  Subsection  1.4  describes  the  major  tasks  in  the 
ETES  development  project.  Subsection  1.5  presents  a 
detailed  description  of  the  progress  achieved  under  each  of 
these  tasks  during  the  first  year  of  the  study. 

1 . 1  BACKGROUND 

The  Early  Training  Estimation  System  will  provide  a 
capability  for  systematically  estimating  training 
requirements  during  the  earliest  phases  of  the  acquisition 
process  (mission  area  analysis,  concept  exploration  -  Phase 
I,  and  validation  and  demonstration  -  Phase  II).  There  are 
two  major  reasons  why  such  early  estimates  of  training 
requirements  are  needed.  First,  by  developing  earlier  and 
more  accurate  estimates  of  training  requirements,  the 
training  planning  process  can  begin  earlier,  and  thus  the 
training  products  associated  with  a  system,  many  of  which 
require  a  long  lead  time,  are  more  likely  to  be  available 
when  the  system  is  fielded.  Second,  by  developing  estimates 
of  training  requirements  for  the  various  alternatives  which 
are  likely  to  exist  during  the  early  phases  of  the 
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acquisition  process,  the  training  developer  can  provide  the 
information  needed  to  effectively  influence  design  with 
training-related  considerations.  The  importance  of  the 
latter  utilization  of  early  training  projections  cannot  be 
overestimated.  Most  of  the  major  design  decisions  related 
to  a  new  system  are  made  during  the  early  phases  of  the 
acquisition  process  (see  Figure  1-1).  Thus,  if  training  is 
to  influence  design,  it  must  impact  these  early  design 
decisions.  And  there  is  good  reason  for  insuring  that 
training-related  considerations  do,  in  fact,  impact 
design.  Studies  have  shown  that,  in  most  weapon  systems, 
operation  and  support  costs  comprise  50  to  80  percent  of 
total  life  cycle  cost.  Further,  over  60  percent  of  these 
operation  and  support  costs  are  related  to  manpower, 
including  the  cost  of  training.  Because  these  costs  are  the 
result  of  demands  generated  by  the  design  characteristics  of 
a  system,  acquisition  policies  have  been  established  in  the 
Federal  Government  to  injure  that  support  requirements  are 
accurately  determined  and  evaluated  in  conjunction  with 
system  development  (e.g.,  DoDD  5000.1,  DODI  5000.2,  and  DODD 
5000.39).  ETES  is  specifically  designed  to  provide  the  Army 
with  the  capability  for  meeting  the  training  -  related 
requirements  in  these  new  acquisition  policies. 

1.2  CURRENT  PROBLEMS  SURROUNDING  EARLY  TRAINING  ESTIMATION 


Given  the  clear  needs  for  early  training  estimation  which 
were  outlined  above,  one  might  wonder  why  a  systematic  early 
training  estimation  tool  has  not  yet  been  developed.  There 
are  two  reasons  for  this  current  gap.  First,  the  needs 
described  in  Section  1.1  have  only  recently  been 
identified.  Second,  and  most  important,  current  procedures 
and  practices  have  three  major  deficiencies  which  limit,  and 
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in  most  cases  prohibit,  the  development  of  early  estimates 
of  training  requirements.  These  deficiencies  are: 

( 1 )  Lack  of  a  Systematic  Flow  of  Information  Between 
Training  Developers  and  Other  Participants  in  the 
Acquisition  Process  -  To  develop  estimates  of 
training  requirements,  training  developers  must 
have  information  on  actual  or  estimated  system 
functional  requirements  and  design  concepts  as 
soon  as  they  are  generated  and,  to  maintain  the 
accuracy  of  these  estimates,  these  same  training 
developers  must  be  quickly  informed  of  design 
changes  and  updates.  Unfortunately,  under  current 
practices  and  procedures,  training  developers  do 
not  receive  information  on  system  functional 
requirements  and  design  concepts  in  any  systematic 
format,  nor  is  there  any  formal  mechanism  through 
which  they  can  obtain  information  on  system 
updates. 

(2)  Lack  of  Estimation  Procedures/Aids  Appropriate  to 
the  Design  Process  -  Even  if  training  developers 
were  receiving  accurate  and  timely  information  on 
early  system  concepts,  systematic  estimates  of 
training  resources  could  not  be  developed  because 
of  the  deficiencies  in  the  current  state  of  the 
art  in  training  estimation  procedures  and  aids. 
Current  training  technologies  are  geared  to  deal 
with  the  type  of  detailed  data  and  the  types  of 
analytical  questions  which  are  relevant  to  later 
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the 

acquisition 

process. 

These 

technologies 

cannot 

deal 

with 

the 

special 

requirements 

of 

the 

early 

phases 

such 

as  the 
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identification  of  comparable  existing  equipment, 
the  generation  of  tasks  for  systems  whose  hardware 
has  not  yet  been  built,  the  rapid  assignment  of 
tasks,  and  the  rapid  estimation  of  training 
resources  and  costs. 

(3 )  Lack  of  Simulation  Models  and  Other  Evaluative 

Technologies _ which _ Incorporate _ Human 

Performance .  Currently,  there  is  not  an  adequate 
set  of  simulation  models  which  can  be  used  to 
relate  human  task  performance  to  overall  system 
performance.  Without  such  models,  it  is  difficult 
to  estimate  some  of  the  key  interdisciplinary 
tradeoffs  (e.g.,  training  versus  hardware)  which 
must  be  made  during  the  early  phases  of  the 
acquisition  process. 

1.3  ETES  COMPONENTS 

To  deal  with  the  deficiencies  described  above  and  to  develop 
a  comprehensive  set  of  early  training  estimation  tools,  the 
Army  Research  Institute  (ARI)  initiated  a  three-year  effort 
to  develop  an  Early  Training  Estimation  System  (ETES).  The 
ETES  will  have  four  major  components:  a  System  Description 
Technology  ( SDT ) ,  Training  Estimation  Aids  and  Procedures, 
Human  Performance  Simulation  Models,  and  a  User’s  Guide. 

1.3.1  System  Description  Technology  (SDT) 

The  SDT  will  be  an  automated  tool  for  describing  actual  and 
projected  system  elements,  including  functional 
requirements,  design  concepts,  tasks,  skills,  training 
program  elements,  and  their  associated  resources;  for 
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storing  the  above  information;  for  changing  and  updating 
this  information;  and  for  transmitting  the  information  among 
all  of  the  participants  in  the  acquisition  process. 

The  SDT  is  clearly  the  most  important  component  of  ETES  and 
will  be  given  the  greatest  amount  of  attention  and  resources 
during  development.  In  fact,  the  primary  focus  of  the  first 
year  of  the  study  efforts  has  been  on  the  development  of 
specifications  for  the  SDT. 


It  should 

be  not  ad  that  even  though  the  SDT  is  being 

developed  under  the  auspices  of  an  early  training  estimation 

project,  the  SDT  will  provide  a  data  base  management  tool 

which  will 

be  capable  of  describing  most  of  the  major 

elements  of 

a  system  (e.g.,  functional  requirements,  design. 

tasks,  skills,  and  training  program  elements).  As  such,  the 

SDT  will 

provide  an  important  data  base  management 

capability 

that  has  wide  ranging  applicaoility  beyond 

training  related  issues. 

To  provide  an  effective  communication  vehicle  for  training 
developers  ana  other  participants  in  the  acquisition 
process,  the  SDT  will  describe  (a)  training  programs  and 
their  associated  resources,  Co)  the  tasks  which  drive  these 
training  programs,  (c)  the  personnel  who  will  be  required  to 
perform  the  tasks,  (d)  the  system  designs  which  generate  the 
task  requirements,  and  (e)  the  functional  requirements  for 
which  the  system  designs  have  been  developed. 

In  order  to  provide  a  capability  for  early  training 
requirements  estimation,  the  SDT  will  describe  these  system 
elements  during  the  earliest  phases  of  the  acquisition 
process.  To  systematically  generate  data  during  the  early 


phases  of  the  acquisition  process,  comparability  analysis 
procedures  will  be  employed. 

More  specifically,  during  the  early  phases  of  the 
acquisition  process  when  only  information  on  functional 
requirements  is  available,  a  systematic  comparability 
analysis  can  be  conducted  to  identify  existing  subsystems, 
and  historical  data  for  these  subsystems  can  be  modified  to 
meet  the  differential  requirements  of  the  new  system.  By 
utilizing  design  and  task  data  from  comparable  existing 
systems,  systematic  estimations  of  early  training 
requirements  can  be  made  when  only  functional  information  on 
the  projected  system  is  available  (see  Figure  1-2).  Later, 
as  actual  design  concepts  are  developed,  the  comparability 
analyses  can  be  used  to  develop  estimates  of  tasks  and 
training  program  elements.  Still  later,  when  the  actual 
system  tasks  are  available,  only  the  training  program 
elements  must  be  estimated. 

The  SDT  will  thus  be  capable  net  only  of  describing  the 
current  state  of  the  system  during  the  earliest  phases  of 
the  acquisition  process,  but  also  of  (1)  detailing  projected 
system  elements  and  alternative  system  concepts,  (2) 
relating  alternative  system  concepts  to  a  common  framework 
so  that  meaningful  comparisons  can  be  made,  and  (3)  refining 
system  information  as  more  accurate  and  more  detailed  data 
are  developed. 

1 . 3 • 1 . 1  SDT  as  a  Data  Base  Management  Tool 

An  extensivo  review  of  automated  tools  was  conducted  during 
the  first  year  of  the  ETES  study  to  identify  an  extant 
technique  or  approach  which  would  provide  the  best  vehicle 
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FIGURE  12  SYSTEM  DEVELOPMENT  PROCESS  FOR  SOT 


for  STD  development.  The  results  of  this  review  indicated 
that  a  Data  Base  Management  System  (DBMS)  could  best  fill 
the  SDT  requirements.  The  Data  Base  Management  System 
concept  has  a  number  of  advantages  over  other  automated 
tools.  First,  DBMSs  are  specifically  designed  to  deal  with 
the  types  of  issues  which  are  central  to  the  major  problem 
facing  the  SDT  -  namely,  the  description,  update,  expansion 

and  retrieval  of  data  on  an  emerging  system  and  the 

transmission  of  this  information  to  a  wide  range  of  users. 
Second,  DBMSs  have  the  capability  to  be  fitted  with 

input/output  mechanisms  which  are  specifically  geared  for 
use  by  uninitiated  users.  Third,  DBMSs  can  incorporate 
information  on  the  implicit  relationships  and  classes  of 
information  which  are  applicable  to  all  weapon  systems  and 
these  stored  relationships  can  be  used  to  reduce  the  input 
load  on  the  user.  Fourth,  DBMSs  can  maintain  a  consistent 
internal  data  base  while  at  the  same  time  allowing  different 
users  to  have  different  "views**  of  the  stored  data  and 

different  input  and  output  requirements. 

The  centralized  control  provided  by  a  DBMS  can,  in  turn,  (1) 
reduce  redundancy  in  stored  data,  (2)  avoid  inconsistency  in 
stored  data,  (3)  allow  for  greater  sharing  of  dfcta,  (4) 
permit  standards  to  be  enforced,  (5)  permit  security 
restrictions  to  be  applied,  (6)  permit  a  greater  capability 
for  checking  and  maintaining  data,  and  (7)  provide  a 
capability  for  "data  independence".  Data  independence  is 
achieved  by  maintaining  an  internal  structure  of  the  data 
which  is  independent  of  the  individual  applications  of  the 
data  and  individual  user  viewpoints.  This  data  independence 
may  be  contrasted  with  data  dependent  systems  in  which  the 
data  are  stored  and  accessed  in  a  manner  which  is  dictated 
by  the  structure  of  the  applications. 
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1.3. 1.2  Users  of  SDT 


Some  of  the  organizations  which  are  likely  to  be  users  of 
the  SDT  are  the  TRADOC  system  manager  for  a  developing 
system,  training  developments  (for  the  related  school) 
combat  developments,  DARCOM  Program  Management  staff  for  the 
developing  system,  the  TRADOC  Systems  Analysis  Activity 
(TRASANA),  the  DARCOM  Materiel  Readiness  Support  Activity 
(MRSA),  and  individual  contractors  associated  with  the 
System. 

Each  user  will  be  connected  to  the  SDT  by  at  least  oue 
remote  terminal.  Some  primary  user  organizations  (e.g., 
training  developments  and  the  DARCOM  Program  Manager)  are 
likely  to  have  more  than  one  terminal  since  they  will  have  a 
number  of  individuals  with  a  need  for  SDT  data  base 
information.  It  is  expected  that  the  users  of  the  SDT  w.ll 
have  little,  if  any,  computer  skills.  Consequently,  all  of 
their  interactions  with  the  SDT  will  be  through  a  highly 
transparent  user  interface  which  will  utilize  menu- 
selection,  form-filling,  and  question-and-answer  computer 
dialogue  techniques  to  elicit  input  data  and  commands.  This 
type  of  transparent  interface  will  mean  that  the  users  will 
be  required  to  learn  only  the  commands  associated  with 
calling  up  the  SDT  system.  From  that  point  on,  they  will  be 
led  through  the  utilization  of  the  SDT  and  will  not  have  to 
generate  any  more  commands  on  their  own.  (They  should,  of 
course,  have  read  the  SDT  Users  Manual  to  learn  how  the  SDT 
can,  and  should,  be  used.) 

One  of  the  user  groups  will  also  serve  as  the  Data  Base 
Directors  ( DBDs ) .  The  D8Ds  will  have  the  same  capability  as 
the  primary  users  for  entering,  ttoring,  and  accessing  SDT 
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information.  The  Data  Base  Directors  will  also  have  two 
additional  responsibilities:  (1)  The  DBDs  will  be 

responsible  for  overseeing  the  general  development  of  a 
system-specific  SDT  data  base,  and  (2)  The  DBDs  will  have 
the  capability,  together  with  the  SDT  Management  Group,  for 
batch  input  and  for  producing  block  diagrams  to  represent 
various  system  relationships. 

The  SDT  Management  Group  will  be  responsible  for  overseeing 
the  application  of  the  SDT  on  an  Army-wide  basis  including 
the  maintenance  and  update  of  the  SDT  data  base  programs 
relating  to  data  input  and  output,  data  storage  and 
retrieval  and  the  DBMS  external,  conceptual,  and  internal 
models?  operation  of  the  central  processor  to  handle  SDT 
applications  and  direct  its  use  among  the  various  SDT  users? 
assistance  to  users  and  DBDs  in  utilizing  the  SDT?  and 
provision  of  data  to  other  Army  organizations  for  related 
applications  (e.g.,  total  force  requirements  analysis). 

1.3. 1.3  Physical  Description  of  SDT 

Figure  1-3  provides  a  general  description  of  the  SDT 
physical  characteristics.  The  design  outlined  in  Figure  1-3 
is  intended  to  minimize  requirements  for  the  purchase  of  new 
equipments  by  participating  Army  organizations. 

1.3. 1.4  Overview  of  SDT  Processes 

An  overview  of  the  general  SDT  processes  is  presented  in 
Figure  1-4.  The  SDT  will  have  the  capability  of  inputting 
data  in  two  different  modest  batch  input  of  SDT  data  sheets 
and  acquisition  data,  and  interactive  input  of  SDT  data 
sheets.  Directions  for  the  interactive  input  of  data  will 
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FIGURE  13  OVERVIEW  OF  SOT  PHYSICAL  STRUCTURE 
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be  provided  by  the  data  base  director  programs.  The  SDT 

input  data  will  be  translated  into  a  form  which  matches  an 
internal  conceptual  model  contained  in  the  DBMS.  Once  it 

has  been  translated,  the  data  will  be  evaluated  for 
consistency  against  data  already  in  the  data  base  and,  if 
consistent,  the  data  will  be  entered  into  the  system- 
specific  data  base.  However,  this  will  be  done  only  after 
the  Data  Base  Directors  have  determined  that  thj  user  has 
been  cleared  to  enter  that  type  of  data  into  the  data  base. 
Once  in  the  data  base,  the  data  are  continuously  updated, 
modified,  and  expanded.  Direction  of  these  changes  is 
provided  by  the  data  base  director  programs.  These  same 
programs  are  used  it.  selecting  and  generating  output  data. 
Five  different  formats  for  outputing  the  data  will  be 
available;  specialized  SDT  lists,  standard  SDT  lists,  block 
diagrams,  output  formatted  for  input  into  other  ETES 
procedures,  and  output  fo.  netted  to  correspond  to  the  format 
requirements  of  specific  acquisition  documents. 

Once  the  user  enters  the  SDT,  he  will  have  option  of 
entering  four  possible  inodes  of  operation;  (1)  system 
examination  -  this  mode  is  used  to  examine  data  which  is 
currently  in  the  data  base;  (2)  input  -  this  mode  is  used  to 
input  data;  (3)  update/modify  -  this  mode  is  used  to 
eliminate  or  modify  data  already  in  the  data  base;  and  (4) 
output  -  this  mode  is  used  to  obtain  a  hard  copy  output  of 
elements  in  the  data  base. 

1.3.2  Training  Estimation  *ids  and  Procedures 

These  aids  and  procedures  can  be  divided  into  two  general 
groups:  training  data  generation  techniques  and  training 

estimation  techniques.  The  data  generation  techniques  are 
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procedures  for  identifying  comparable  equipments,  generating 
and  modifying  tasks,  and  generating  and  modifying  courses. 
The  training  estimation  techniques  include  procedures  for 
selecting  and  assigning  tasks  to  training  settings  and 
methods,  determining  the  number  of  personnel  to  be  trained, 
determining  training  resources,  and  determining  training 
costs. 

The  ETES  development  study  will  focus  on  the  development  of 
the  data  generation  techniques.  For  the  most  part,  training 
estimation  techniques  will  not  be  developed  during  the  ETES 
study.  Instead,  ETES  will  incorporate  existing  estimation 
procedures  and  procedures  currently  being  developed  under 
other  ARI  projects  (e.g.  HARDMAN,  Training  Developers 
Decision  Aid) . 

1.3.3  Human  Simulation  Models 

These  models  will  relate  human  task  performance  to  overall 
system  performance.  Input  for  the  models  will  be  provided 
by  the  data  contained  in  the  SDT .  By  relating  task 
performance  to  system  performance,  the  simulation  models 
will  provide  the  capability  for  trading  off  training-related 
systems  elements  against  other  system  elements. 

ARI  currently  has  an  ongoing  project  (i.e.  MOPADS)  at  ARI, 
Fort  Bliss,  to  develop  advanced  human  simulation  models. 

However,  these  models  are  rather  sophisticated  and  are  more 
relevant  to  the  types  of  detailed  human  performance 
questions  generated  during  the  later  phases  of  the 
acquisition  process.  Hence,  the  ETES  will  focus  on  (1)  the 
development  of  less  detailed  simulation  models  which  can  be 
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meaningfully  applied  to  the  types  of  general  questions  which 
are  relevant  during  the  early  phases  of  the  acquisition 
process  and  (2)  the  incorporation  of  the  MOPADS  data 
requirements  into  the  SDT  specifications.  The  latter  effort 
will  insure  that  the  SDT  will  be  able  to  feed  MOPADS 
simulation  models  as  appropriate  during  the  acquisition 
process . 

1.3.4  User's  Guide 

The  User's  Guide  will  provide  a  detailed  step-by-step 
handbook  describing  how  the  other  three  ETES  tools  can  and 
should  be  used  to  assess  early  training  requirements. 

1.4  ETES  STUDY  TASKS 

The  ETES  study  is  broken  down  into  five  basic  tasks.  Figure 
1-5  displays  an  up-to-date  description  of  these  tasks.  (The 
terminology  of  the  tasks  has  been  changed  slightly  to 
reflect  insights  developed  during  the  first  year  of  the 
study. ) 

1.5  PROGRESS  ON  STUDY  TASKS 

Table  1-1  displays  the  activities  accomplished  under  each 
task  and  the  sections  of  the  report  relating  to  these 
activities.  More  details  are  provided  below. 

1.5.1  Task  1:  Review  of  Existing  Procedures 

This  task  began  with  a  review  of  existing  DoD  Army  doctrine 
and  operating  procedures  related  to  early  training 
estimation  and  system  description.  The  purpose  of  this 
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TABLE  1-1  ETES  STUDY  ACTIVITIES  AND  RELATED  SECTIONS  OF  THE  REPORT 


■i*. 
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review  was  to  identify  needs  and  problems  associated  with 
current  procedures  and  potential  roles  for  ETES  in 
ameliorating  these  problems.  This  review  was  supplemented 
by  a  number  of  interviews  with  users  in  the  field.  The 
results  of  the  review  and  interviews  were  assessed  and 
integrated  into  a  description  of  the  current  acquisition 
process.  The  gaps  in  this  process  were  associated  with 
early  training  estimation  and  system  description  and  the 
likely  role  of  the  SDT  (see  Appendix  A). 

In  addition  to  the  review  of  existing  Army  procedures,  four 
different  behavioral/ information  science  areas  related  to 
the  SDT  were  reviewed:  human  resource  data,  automated  tools 
which  might  serve  as  a  possible  vehicle  for  the  SDT, 
psychological  research  related  to  design,  and  research  on 
human-computer  interactions  (see  Section  2.4,  Section  3.0, 
Appendix  C,  and  Appendix  D  respectively). 

Psychological  research  related  to  design  was  examined  to 
identify  the  individual  cognitive  processes  relevant  to 
early  system  design  and  description.  The  review  of  human- 
computer  interacticn  was  conducted  to  identify  guidelines 
for  construction  of  the  SDT  human-computer  interface. 

1.5.2  Task  2:  Develop  SDT 

Utilizing  the  information  developed  in  the  previoius  steps, 
a  detailed  description  of  the  data  elements  to  be  described 
by  the  SDT  was  developed  (see  Section  2).  A  particular 
class  of  automated  tods  (data  base  management  systems)  was 
then  selected  and  specific  tools  within  this  class  were 
examined  in  detail  (see  Section  3).  Finally,  a  detailed 
description  of  the  SDT  users,  physical  characteritics. 
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input/output  mechanisms,  and  operational  characteristics  was 
developed  (see  Section  4). 

1.5.3  Tasks  3,  4  and  5 

These  three  tasks  will  be  performed  during  the  remaining 
portion  of  the  ETES  study. 
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SECTION  2  -  SPECIFICATIONS  FOR  SDT 


This  section  provides  a  detailed  set  of  specifications  for 
the  functions  which  must  be  performed  by  the  SDT,  and  a 
genera?  set  of  requirements  for  the  mechanisms  which  must  be 
utilized  to  perform  these  functions. 

The  specifications  described  in  this  section  were  developed 
by  examining  (a)  current  Army  procedures  for  system 
development,  requirements  analysis  (functional  analysis), 
task  generation,  and  training  development;  (b)  non-Army 
research  and  work  in  these  four  areas;  (c)  previous  attempts 
to  develop  system-specific  human  resource  data  bases;  and 
(d)  previous  discussions  of  SDT  requirements  in  Status 
Report  1,  Status  Report  2,  and  Status  Report  3. 

The  section  is  divided  into  five  subsections.  The  first 
subsection  provides  an  overview  of  the  functional 
requirements  which  must  be  accomplished  by  the  ETES.  The 
second  subsection  provides  a  detailed  description  of  the 
ETES  functions  and  the  types  of  output  data  associated  with 
each  function.  The  third  subsection  outlines  some  general 
requirements  for  SDT  data  input/output  mechanisms.  The 
fourth  subsection  provides  a  preliminary  listing  of  the 
sequence  in  which  the  SDT  functions  must  be  performed.  The 
fifth  subsection  briefly  reviews  past  efforts  which  have 
attempted  to  identify  what  should  be  in  system-specific 
human  resource  data  bases. 
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2.1  OVERVIEW  OF  SDT  REQUIREMENTS 


The  SDT  is  one  of  four  major  components  of  the  Early 
Training  Estimation  System  (see  Figure  2-1).  The  SDT  is 
clearly  the  most  important  component  of  ETES  since  it 
provider  all  the  basic  system  information  required  by  the 
other  ETES  components.  (This  importance  is  reflected  in  the 
amount  of  resources  and  time  devoted  to  SDT  development.) 

The  basic  goal  of  the  SDT,  as  outlined  on  page  three  of  the 
ETES  study  RFP,  is  to: 

.  .  .  provide  the  Army  training  and  hardware 

development  community  with  an  advanced  technology  for 
early  generation  of  improved  system  descriptions 
suitable  for  input  into  emerging  automated  training  and 
hardware  development  aids. 

To  effectively  estimate  early  training  resource 
requirements,  the  SDT  must  describe  (a)  training  programs 
and  their  associated  resources,  (b)  the  tasks  which  drive 
these  training  programs,  (c)  the  system  designs  which 
generate  the  task  requirements,  and  (d)  the  functional 
requirements  for  which  the  system  designs  have  been 
developed.  An  overview  of  the  application  of  the  SDT  to 
these  four  system  elements  and  their  role  in  system 
development  is  described  in  Figure  2-2. 

In  its  initial  application  to  a  system,  the  SDT  is  used  to 
describe  the  system  functional  requirements  which  are 
generated  during  functional  analysis.  These  requirements 
specify  the  functions  which  must  be  performed  if  the  system 
is  to  satisfy  its  designated  need.  The  SDT  can  be  applied 
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FIGURE  22  SOT  APPLICATION 
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in  a  functional  analysis  as  soon  as  the  need  for  a 
particular  system  has  been  specified.  Formally,  this  occurs 
at  the  approval  of  the  requirements  document  at  Milestone  0, 
the  milestone  which  initiates  the  Concept  Exploration  phase 
of  the  acquisition  process.  However,  in  actuality,  the  SOT 
could  probably  be  used  to  describe  functional  requirements 
even  prior  to  Milestone  0  if  the  need  for  a  particular 
system  had  been  identified  earlier. 

Once  the  functional  requirements  for  a  system  have  been 
developed  and  described  via  the  SDT,  system  designs  can  be 
generated.  These  designs  specify  possible  mechanisms  for 
performing  the  desired  functions.  These  mechanisms  include 
equipment,  personnel,  and  software.  Once  developed,  the 
system  design  can  also  be  described  with  the  SDT. 

Once  the  mechanisms  for  achieving  the  functions  have  been 
identified  in  the  design  concepts,  the  human  tasks  which 

must  be  performed  to  utilize  the  system  designs  can  be 
specified.  These  tasks,  which  are  the  key  building  blocks 
of  training  development,  must  also  be  carefully  documented 
in  the  SDT.  With  the  tasks  identified  and  specified  in  the 
SDT,  training  estimation  aids  and  procedures  can  be  used  to 
determine  training  program  elements,  estimate  training 
resources,  and  develop  training  products.  The  resulting 
training  program  and  its  associated  resources  can  then  be 

documented  in  the  SDT. 

2.1.1  Role  of  SDT  in  the  Acquisition  Process 

The  SDT,  like  the  other  components  of  ETES,  is  primarily 

designed  for  application  during  the  Concept  Exploration 
phase  of  the  acquisition  process,  which  runs  from  Milestone 


O  to  Milestone  1  (see  Figure  2-3).  However,  the  SDT  may 
also  be  used  during  mission  area  analysis  if  the  need  for  a 
particular  system  has  been  specified.  (Again,  it  should  be 
noted  that  this  is  likely  to  occur  between  the  time  the 
decision  is  made  to  develop  a  requirements  document  and  its 
final  approval  at  Milestone  0.)  In  addition,  the  SDT  may  be 
used  during  the  phases  of  the  acquisition  process  which 
follow  Concept  Exploration.  The  primary  purposes  of  the  SDT 
applications  during  the  later  phases  would  be  to  (1) 
estimate  mors  detailed  tasks  and  training  resource 
requirements,  (2)  determine  the  impact  of  subsequent  design 
changer  on  task  and  training  requirements  via  the  data  base 
management  capabilities  of  the  SDT,  and  (3)  to  develop 
general  estimates  of  task  and  training  requirements  for 
systems  which  fr'l  behind  schedule. 

2.1.2  A  Basic  Data  Problem  in  Early  Training  Estimation 

To  provide  the  necessary  information  for  early  training 
estimation,  the  SDT  must  describe  functional  requirements, 
system  designs,  tasks,  and  training  program  elements  during 
the  earliest  phases  of  the  acquisition  process.  However, 
there  is  a  basic  data  problem  confronting  the  analyst  who 
attempts  to  develop  such  a  description.  During  the  earliest 
phases  of  the  acquisition  process,  only  functional 
requirements  or  very  general  design  concept*  are  available — 
information  on  tasks  which  are  the  critical  building  blocks 
of  training  is  generally  not  available.  Thus,  if  the  SDT 
were  simply  to  describe  the  current  state  of  the  system 
during  the  earliest  phases  of  the  Weapons  System  Acquisition 
Process  (WSAP),  estimation  of  training  resources  would  not 
be  poesible  since  the  data  needed  for  training  estimation  do 
not  exist  during  this  phase. 
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FIGURE  23  ROLE  Or  SOT  DURING  ACQUISITION  PROCESS 
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•  Solution  to  Data  Problem 

To  circumvent  the  data  problems  described  above,  the 
following  procedure  can  be  employed.  During  the  earliest 
phases  of  the  acquisition  process  when  only  information  on 
functional  requirements  is  available,  a  systematic 
comparability  analysis  can  be  conducted  to  identify  the 
existing  subsystems  which  must  closely  meet  the  projected 
requirements  of  the  new  system.  Data  on  these  comparable 
systems  can  then  be  obtained  and  modified  to  meet  the 
differential  requirements  of  the  new  subsystem.  Thus,  by 
utilizing  design  and  task  data  from  comparable  existing 
systems,  systematic  estimations  of  early  training 
requirements  can  be  made  when  only  functional  information  on 
the  projected  system  is  available  (see  Figure  2-4).  Later, 
as  actual  design  concepts  are  developed,  the  comparability 
analyses  can  be  used  to  develop  estimates  of  tasks  and 
training  program  elements.  Still  later,  when  the  actual 
system  tasks  are  available,  only  the  training  program 
elements  must  be  estimated. 

•  Implications  for  SDT 

The  above  discussion  indicates  that  the  SDT  must  not  only  be 
capable  of  describing  the  current  state  of  the  system  during 
the  earliest  phases  of  the  acquisition  process,  it  must  also 
be  capable  of  (1)  describing  projected  system  elements  and 
alternative  system  concepts,  (2)  relating  alternative  system 
concepts  to  a  common  framework  so  that  meaningful 
comparisons  can  be  made,  and  (3)  updating  and  refining 
system  information  as  more  accurate  and  more  detailed  data 
is  developed. 
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2.2  OVERVIEW  OF  SDT  FUNCTIONS 


To  develop  more  detailed  specifications  for  the  SDT,  a 
functional  analysis  was  performed  on  the  SDT  itself  and  the 
results  of  this  analysis  were  documented  in  a  series  of 
hierarchical  functional  diagrams.  Figure  2-5  provides  an 
overview  of  the  system  elements  which  must  be  described  by 
the  SDT.  The  elements  are  comparable  to  the  four  system 
elements  described  in  previous  sections  (functional 
requirements,  design  concept,  tasks,  and  training  program 
elements).  However,  tasks  are  broken  down  into  three 
functions  (equipment-task  interface,  behavioral  task 
elements  and  features,  and  skills  and  knowledges)  because 
more  detailed  descriptions  are  required  in  each  of  the  task 
areas. 

Each  function  in  the  diagram  is  coded  to  indicate  what  its 
developmental  priority  should  be  during  the  construction  of 
the  SDT.  Functions  labeled  ’’l"  have  the  highest  priority 
and  should  be  included  in  the  earliest  versions  of  the 
SDT.  Functions  labeled  "2"  have  the  next  highest  priority 
and  functions  labeled  "3"  have  the  lowest  priority. 

The  major  factors  used  in  assigning  developmental  priorities 
to  the  functions  were  (1)  relevance  to  task  generation — 
functions  related  to  information  which  was  required  for  task 
generation  were  given  a  higher  priority  than  functions  which 
were  not,  (2)  relevance  to  the  Concept  Exploration  phase — 
acquisition  process  functions  which  were  more  likely  to  be 
utilized  during  the  Concept  Exploration  phase  were  given 
higher  priority,  (3)  adequacy  of  present  description 
formats — functions  which  are  not  being  described  adequately 
via  present  procedures  were  given  high  priority,  (4) 
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FIGURE  2-5 
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relevance  to  training  developer  input  needs — information 
that  must  be  provided  _to_  the  training  developer  tended  to  be 
given  a  higher  priority  than  information  developed  b£  the 
training  developer. 

2.2.1  Functional  Requirements 

Figure  2-6  lists  the  SDT  functions  which  must  be 
accomplished  during  functional  requirements  analysis.  Table 
2-1  lists  the  outputs  that  must  be  produced  for  these 
functions.  Examples  of  each  of  these  outputs  are  provided 
in  Appendix  B.  These  examples  should  only  be  considered  as 
preliminary  estimates  of  output  formats.  The  ex*ct  ^tput 
format  will  depend  on  the  mechanisms  which  are  selected  to 
accomplish  each  function.  The  examples  are  only  designed  to 
represent  the  "types  of  information"  which  should  be 
provided  as  output. 

The  first  three  system  elements  related  to  functional 
requirements  (hierarchical  structure,  activity  flow,  and 
information  flow)  are  concepts  which  are  taken  directly  from 
recent  discussions  of  software  requirements  analysis  and  are 
defined  as  follows: 

•  Hierarchical  Structure  -  the  hierarchical 
arrangement  of  functions  and  their  corresponding 
subfunctions. 

•  Activity  Flow  -  a  representation  of  the  sequence 
in  which  system  functions  are  performed  during  the 
mission. 
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FIGURE  2-6  FUNCTIONAL  REQUIREMENTS 
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Table  2-1  OUTPUTS  RELATED  TO  FUNCTIONAL  REQUIREMENTS 


OUTPUT  PRIORITY 

•  List  Hierarchical  Structure  (1) 

•  List  Activity  Flow*  (1) 

•  List  Information  Flow*  (1) 

•  List  Performance  Goals  by  Function  (1) 

•  List  Terrain  Impacts  on  Functions*  (1) 

•  List  Threat  Impacts  on  Function*  (1) 

•  List  Mission  Profile  Impacts  on  Functions  (1) 


•Tentatively  for  operational  functional  requirements  only.  May  also  be  used 
with  selected  maintenance  functions. 
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•  Information  Flow  -  the  flow  of  inputs  and  outputs 
(in  informational  terms)  between  system  functions 
and  between  system  functions  and  the  external 
environment . 

At  the  highest  level,  it  is  likely  that  the  mission-related 
functional  requirements  of  each  system  can  be  broken  down 
into  four  major  functional  areas  (see  Figure  2-7 ).* 

The  performance  goals  for  each  function  are  similar  to  the 
types  of  goals  described  in  requirements  documents  such  as 
the  MENS.  Whenever  possible,  these  goals  must  be  described 
in  quantifiable  terms  with  minimum  and  maximum  allowable 
values  specified.  The  performance  goals  are  extremely 
important  since  they  will  be  the  primary  source  for  the 
identification  of  system  performance  measures  during 
subsequent  training  analyses.  These  performance  measures 
will  be  utilized  in  the  ETES  simulation  models  which  will 
relate  task  performance  to  system  performance. 

The  threat  and  the  terrain  (e.g.,  geography,  climate) 
information  describe  the  external  environment  in  which  the 
system  must  operate.  The  mission  profile  describes  what  the 
likely  goals  of  the  system  will  be.  The  SDT  will  not 
attempt  to  provide  detailed  descriptions  of  the  threat 
terrain  and  mission  profile  as  there  are  likely  to  be 
documents  specifically  devoted  to  accomplish  this  task 
(e.g.,  terrain  and  threat  information  is  contained  in  SCORES 


1  Two  other  system  functional  requirements,  "support  the 
system"  and  "acquire/dispose  the  system"  are  not  directly 
mission-related  and  tentatively  are  not  considered  for 
inclusion  in  the  SDT. 
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BREAKDOWN  FOR  WEAPONS  SYSTEMS 
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documents).  The  SDT  must  simply  summarize  the  important 
variables  in  each  of  these  three  areas,  the  degree  to  which 
the  system  can  be  expected  to  encounter  specific  environ¬ 
ments  or  act  under  each  mission  profile  (in  quantifiable 
terms),  and  the  likely  impact  of  these  variables  on  specific 
system  functions  (Appendix  B) . 

It  should  be  noted  that  the  current  specifications  for  the 
SDT  functional  requirements  do  not  include  descriptions  of 
the  acquisition  goals  (e.g.,  schedule  or  cost  goals). 
(These  goals  had  been  included  in  earlier  versions  of  the 
SDT  specifications.)  The  acquisition  goals  were  purposely 
excluded  from  the  current  SDT  specifications  because  it  was 
determined  that  (1)  acuisition  goals  could  be  described  via 
current  tools  and  (2)  detailed  specification  of  these 
elements  is  not  necessary  for  task  generation. 

2.2.2  Design  Concepts 

Figure  2-8  lists  the  design  concept  elements  which  must  be 
described  by  the  SDT  and  Table  2-2  lists  the  outputs 
estimated  to  be  required  to  accomplish  these  functions. 
Examples  of  each  of  these  outputs  are  provided  in  Appendix 
B. 


The  generic  equipment  functions  list  the  general  type  of 
equipment  (e.g.,  cab,  engine,  hull)  which  can  be  used  to 
satisfy  a  set  of  system  functions  but  do  not  describe  the 
specific  piece  of  equipment  used  to  perform  these  functions 
(e.g.,  M109  cab,  GE  engine).  As  the  design  process 
progresses,  the  approved  design  concept  will  proceed  down 
the  generic  equipment  hierarchy.  In  fact,  it  is  tx>ssible  to 
identify  several  different  levels  of  design  concept 
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FIGURE  2-8  DESIGN  CONCEPTS 


2- 


Funct* 


Table  2-2  OUTPUTS  RELATED  TO  DESIGN  CONCEPTS 


OUTPUT  PRIORITY 

•  List  Hierarchical  Structure  for  Generic  Equipment  (1) 

•  List  Hierarchical  Structure  for  Design  Alternatives  (1) 

•  List  iternative  Design  Concepts  by  Generic  (1) 

Equipment 

•  List  Information  Flow  for  Design  Alternative  (1) 
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development.  These  levels  are  described  in  Table  2-3  a!od 
the  sequence  in  which  the  design  concepts  at  each  of  these 
levels  is  developed  is  listed  in  Figure  2-9.  A  large  scale 
system  which  is  closely  following  the  principles  outlined  in 
OMB  Circular  A109  will  go  through  each  of  the  levels  listed 
in  Table  2-3.^ 

A  smaller  system,  a  system  involving  a  product  improvement, 
or  a  system  not  following  the  principles  outlined  in  A109, 
can  begin  the  design  process  at  a  lower  level  in  the  design 
process. 

2.2.3  Equipment-Task  Interface 

Figure  2-10  lists  the  equipment-task  interface  elements 
which  must  be  described  by  the  SOT  and  Table  2-4  lists  the 
outputs  estimated  to  be  required  to  accomplish  these 
functions. 

Detailed  specification  of  the  task  performance  data  (1.3.2) 
has  not  been  provided  because  the  exact  nature  of  the 
simulation  models  which  will  utilize  this  performance  data 
has  yet  to  be  specified.  It  was  possible  to  estimate  the 
general  types  of  maintenance  performance  data  that  will  be 
required  for  the  maintenance  simulation  model.  These 
estimations  are  based  upon  DRC’s  current  work  in  maintenance 
network  modeling.  It  is  expected  that  the  maintenance 
performance  simulation  model  will  be  based  upon  these 
networks. 


2  OMB  Circular  A-109  indicates  that  initial  system  should 
be  described  in  purely  functional  terms. 
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Table  2-3  LEVELS  OF  DESIGN  CONCEPT  DEVELOPMENT 


LEVEL  1  -  ALTERNATIVE  PLATFOKMS 

Eg,  Self-propelled  howitzer  vs.  multiple  launch  rocket  system. 

Separate  generic  equipment  structures  arc  required  for  each  candidate  platform 
with  commonalities  identified. 

LEVEL  11  -  ALTERNATIVE  GENERIC  SUBSYSTEMS 

Eg,  System  A  uses  fire  control  computer  to  perform  function.  System  B  does 
not  (function  performed  manually). 

Different  generic  equipment  structures  are  required  at  the  subsvtem  level  with 
comrnonal.ties  identified. 

LEVEL  Ill  ALTERNATIVE  SUBSYSTEMS 

Eg.  System  A  uses  GE  engine,  System  B  uses  Chrysler  engine. 

Sume  generic  equipment  structures  at  subsystem  level,  but  different  design 
alternatives  associated  with  these  generic  subsystems 

LEVEL  HI  A  -  ALTERNATIVE  GENERIC  COMPONENTS 

Kg.  System  A  uses  GE  engine  with  new  built-in-test  equipment.  System  B 
does  not. 

Different  generic  equipment  structures  at  l he  component  level. 

LEVEL  III B  -  ALTEKN  AT1VE  COM  PON  KN T$ 

Eg.  System  A  uses  GE  engine  with  existing  carburetor.  System  B  use>  GE 
engine  with  new  carburator. 

Same  generic  equipment  structures  at  the  component  level,  but  different  design 
alternatives  are  associated  with  generic  component. 
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FIGURE  2-9  SEQUENCE  FOR  IDENTIFYING  DESIGN  ALTERNATIVES 


Table  2-4  OUTPUTS  RELATED  TO  EQUIPMENT-TASK  INTERFACE 


OUTPUTS  PRIORITY 

•  List  corrective  maintenance  tasks  by  equipment  and  (1) 

function  for  each  design  ALT 

•  List  preventive  maintenance  tasks  by  equipment  and  (1) 

functon  for  each  design  ALT 

•  List  operator  tasks  by  equipment  and  function  for  each  (1) 

design  ALT 

•  List  impact  of  equipment  modes  on  tasks  (1) 

•  List  reliability  data  and  usage  data  by  equipment  for  (2) 

each  design  ALT 

•  *  List  maintenance  task  sequence,  probability,  and  duration  (2) 

by  equpment  for  each  design  ALT. 

•  *  List  impacts  of  preventative  maintenance  tasks  on  (2) 

corrective  maintenance  tasks  by  equipment  for  each 
design  ALT 

•  *  List  operational  performance  data  by  equipment  for  each  (3) 

design  ALT. 


*It  is  possible  to  group  this  information  under  the  behavioral  task  analysis  area. 
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2.2.4  Behavioral  Task  Elements  and  Features 


Figure  2-11  lists  the  task  information  elements  which  must 
be  described  by  the  SDT  and  Table  2-5  lists  the  outputs 
estimated  to  be  required  to  accomplish  these  functions. 

It  is  possible,  and  in  fact  likely,  that  the  task  activity 
flow  and  task  information  flow  data  will  be  required  as 
input  into  the  task  performance  simulation  models.  If  this 
information  is  required  as  input  into  these  performance 
simulator  models,  it  can  be  included  in  the  SDT  function 
related  to  the  task  performance  (function  1.3.2)  and  need 
not  be  repeated  under  1.4. 

The  task  characteristic  data  will  contain  quantitative 
information  on  the  variables  which  will  be  utilized  in 
algorithms  designed  to  (a)  determine  the  tasks  to  be 
trained,  (b)  assign  tasks  to  training  settings,  (c)  assign 
casks  (or  their  associated  learning  objectives)  to  methods 
and  media.  These  algorithms  will  be  developed  during  the 
construction  of  the  ETES  estimation  aids  and  procedures.  The 
exact  nature  of  the  task  characteristics  cannot  be  specified 
until  further  work  has  been  done  on  the  training  estimation 
aids/procedures . 

The  task  information  included  in  SDT  function  1.4.1  (task 
components)  and  1.4.3  (task  features)  is  designed  to  contain 
all  of  the  relevant  task  elements  contained  in  the 
behavioral  task  description  worksheets  which  are  currently 
applied  in  the  Army,  such  as  LSAR  Data  Sheet  D  specified  in 
MIL-STD-13888-1,  the  Job  and  Task  Analysis  Worksheet  in  the 
Army's  Job  and  Task  Analysis  HaMbook  (TRADOC  PAM  351-4), 
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FIGURE  2*11  TASKS 


Table  2-5.  OUTPUTS  RELATED  TO  TASK  INFORMATION 


OUTPUTS 


PRIORITY 


List  tasks  by  MOS/ASI,  by  skill  level,  or  duty  position 

For  each  taLik .list  conditions;  standards;  initiating  and 
terminating  cues,  number  of  people  performing;  amount 
of  supervision;  test  equipment*  tools,  task  type,  task 
elements;  task  characteristic  ratings  and  training  setting 
assignments 

List  task  activity  flow 

List  tasks  by  task  type 


(1) 

(2) 


(2) 

11; 
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and  the  DoD  guidelines  for  contractor  supplied  task  analyses 
(MIL-STD-1379A  and  DI-H-2025). 

2.2.5  Skills  and  Knowledges 

Figure  2-12  lists  the  skill  and  knowledge  information 
elements  which  must  be  described  by  the  SDT  and  Table  2-6 
lists  the  output  estimated  to  be  required  to  accomplish 
these  functions. 

The  skills  and  knowledges  characteristic  information  will  be 
used  to  categorize  the  skills  and  knowledges  and/or  quantify 
their  characteristics.  These  characteristics  can  be  used  in 
the  algorithms  which  assign  methods  and  media.  Again,  as 
with  the  task  characteristics,  the  exact  nature  of  the 
skills  and  knowledge  characteristics  cannot  be  specified 
until  more  work  on  the  development  of  these  algorithms  has 
been  accomplished. 

2.2.6  Training  Program  Elements 

Figure  2-13  lists  the  training  program  elements  which  must 
be  described  by  the  SDT  and  Table  2-7  lists  the  outputs 
estimated  to  be  required  to  accomplish  these  functions. 

2.3  GENERAL  GUIDELINES  FOR  INPUT/OUTPUT  MECHANISMS 

This  section  describes  some  general  guidelines  for  the 
development  of  the  SDT  input/output  mechanisms. 
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FIGURE  2-12  SKILLS  AND  KNOWLEDGF 
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Table  2-6  OUTPUTS  KELATED  TO  SKILLS  AND  KNOWLEDGE  (S+K) 


C  UTPUTS 


PRIORITY 


List  S+K  hierarchical  structure  for  each  design  alternative 


(3) 


List  S+K  by  tasks,  MOS/ASI,  skill  level, 
for  each  design  ALT. 


and  duty  position 


(3) 
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Table  2-7  OUTPUTS  RELATED  TO  TRAINING  PROGRAM  ELEMENTS 


OUTPUTS 


PRIORITY 


For  each  learning  objective,  list  learning  objective,  (2) 

its  place  in  learning  hierarchy,  related  tasks,  skill  and 
knowledges,  and  learning  objective  type 

List  performance  measures,  related  tasks  and  LO's  and  (2) 

performance  measure  type 

List  courses  and  their  course  sequence  no.,  course  no.  (2) 

course  title,  and  course  length  by  MOS  for  each  design 
alternative 

For  each  course  module  within  a  course,  list  module  (2) 

title,  hours,  method,  student  -  instructor  ratios,  related 
tasks,  skills  and  knowledges,  LO’s,  PMS,  and  media 

List  AKTEP  tasks  ami  manuals  and  liu'ir  related  indiviouai  13) 

tasks 

List  media,  media  type,  related  tasks,  learning  objectives  (2) 

and  training  setting 
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A t  a  general  level  the  SDT  should  ultimately  meet  all  of  the 
following  guidelines:^ 

1.  The  SDT  must  minimize  input  data  requirements. 

The  SDT  must  not  require  users  to  repeatedly  input 
the  same  information  and  must  be  able  to  utilize 
information  in  existing  documents  and  data  banks 
whenever  it  is  possible  to  do  so. 

2.  The  SDT  must  interface  with  existing  acquisiton 

procedures  and  documentation  requirements. 
Whenever  possible,  the  SDT  must  utilize  input  data 
required  by  other  Army  acquisition  procedures 
and/or  provide  output  which  can  be  utilized  in 
these  procedures  with  as  little  modification  as 
possible. 

3.  The  SDT  must  be  “user- friendly . “  The  SDT  must  not 

require  extensive  training  to  use  or  apply,  and 
must  be  usable  by  a  wide  range  of  users.  The 
input  mechanism  should  be  as  ‘’transparent”  as 

possible  so  that  user  responses  can  be  elicited  by 
the  SDT  and  user's  are  not  required  to  commit 
large  amounts  of  SDT-related  information  to 
memory.  In  line  with  this,  the  SDT  must  not 
require  the  user  to  learn  complicated  computer 
languages. 


3  It  may  not  be  possible  to  stay  within  all  of  tht 
guidelines  with  the  initial  versions  of  the  SDT.  However, 
the  final  version  of  the  SDT  should  meet  all  of  the 
guidelines  listed  in  this  section. 
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The  SDT  must  be  capable  of  supporting  multiple 
users.  SDT  must  be  capable  of  being  accessed  by 
multiple  users  in  several  different  locations. 
The  SDT  data  base  must  be  "secure"  so  that  users 
can  only  modify  that  portion  of  the  data  base  for 
which  they  are  directly  responsible. 

The  SDT  must  be  capable  of  maintaining  data  bases 
for  several  design  alternatives.  The  SDT  must  be 
capable  of  describing  design,  task,  and  training 
program  data  for  several  alternative  concepts  and 
be  capable  of  relating  these  alternative  data 
elements  to  a  common  framework  so  that  meaningful 
comparisons  can  be  developed. 

The  SDT  must  deal  with  frequent  design  changes. 
The  SDT  must  have  the  capability  of  quickly 
providing  users  with  information  on  the  design, 
task,  and  training  program  elements  associated 
with  a  particular  design  change. 

The  SDT  must  be  able  to  deal  with  the  evolutionary 
and  expanding  features  of  developing  systems.  The 
SDT  must  be  capable  oJ  incorporating  increasingly 
detailed  system  information  with  minimum  user 
input  requirements. 

The  SDT  must  be  flexible  enough  to  handle  a 
variety  of  different  types  of  input.  Thus,  it 
must  have  the  capability  of  handling  both  batch 
and  interactive  inputs. 
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9.  The  SDT  must  also  be  fLexible  enough  to  provide  a 
variety  of  different  types  of  outputs  including 
lists,  block  diagrams,  and  formatted  outputs 
appropriate  for  use  in  other  ETES  procedures  and 
other  acquisition  processes. 

10.  To  keep  implementation  costs  to  a  minimum,  the  SDT 
should,  to  the  maximum  extent  possible,  be 
compatible  with  equipment  (e.g.,  computer 
terminals)  which  is  currently  being  used  by  the 
Army  organizations  who  will  employ  the  SDT. 

11.  To  facilitate  both  software  development  and  system 
flexibility,  the  SDT  must  be  capable  of 
maintaining  a  central  data  base  structure  which  is 
"independent**  of  the  specific  user  applications 
programs  which  access  it. 

2.4  SEQUENCE  OF  SDT  APPLICATIONS  THROUGHOUT  THE  ACQUISITION 

PROCESS 

This  section  outlines,  at  a  general  level,  how  the  SDT  might 
be  applied  during  the  system  development  process.  This 
outline  describes  the  general  sequence  and  types  of  SDT 
applications  which  are  appropriate  for  different  stages  of 
system  development.  This  section  does  not  attempt  to 
provide  detailed  description  of  the  SDT  utilization.  Thus, 
it  does  not  describe  the  specific  organizations  which  will 
utilize  the  SDT  or  the  documents  and  processes  which  will 
feed  into  or  utilize  the  SDT.  Identification  of  the  exact 
users  of  the  SDT  must  be  made  by  the  Army — however,  likely 
potential  users,  at  a  general  level,  are  listed  in  the 
description  of  the  final  SDT  in  Section  4. 
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The  differing  applications  of  the  SDT  throughout  the 
acquisition  process  are  grouped  into  a  series  of  discrete 
periods  (see  Figure  2-14).  Descriptions  of  these  periods 
are  provided  in  the  subsections  which  follow.^ 

2.4.1  Period  Is  Initial  Functional  Requirement  Analysis 

This  period  encompasses  the  time  between  the  decision  to 
meet  an  identified  need  with  a  hardware  system  (rather  than 
with  an  organizational  or  operational  change  or  more 
advanced  technology  development)  and  the  time  when  initial 
functional  requirements  are  specified.  Ideally,  the  end 
item  of  this  period  is  a  functional  requirements  description 
that  will  allow  system  designers  to  develop  design  concepts 
down  to  the  subsystem  level.  The  functional  requirements 
developed  during  this  period  will  provide  the  foundation  for 
the  remaining  phases  of  the  acquisition  process.  Thus,  they 
must  be  developed  very  carefully.  The  SDT  can  be  used  to 
describe  the  functional  requirements  which  are  developed 
during  this  phase  including  system  functions,  threat, 
environmental  impacts  on  functions,  mission  profile  and 
desired  performance  goals.  No  estimates  of  training 
resources  are  made  during  this  period  since  such  estimates 
cannot  be  made  until  the  functional  requirements  have  been 
specified. 

•  Major  SDT  Applications  -  Description  of  functional 
requirements  and  provision  of  input  data  into 


4  These  period  descriptions  are  geared  for  major  system 
acquisitions.  A  slightly  different  series  of  SDT 

applications  would  be  required  for  minor  systems  or  for 
product  improvement  changes. 
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requirements  documents  and  other  initial 
acquisition  documents  requiring  information  on 
functional  requirements. 

2.4.2  Period  2:  Initial  Training  Estimation — Contractor 
Design  Alternatives  Not  Specified 

This  period  covers  the  time  between  the  specification  of  the 
initial  functional  requirements  and  the  time  when 
contractors  have  completed  their  initial  design  concepts. 
Thus,  during  this  period  information  on  contractor  design 
concepts  is  not  available.  During  this  period,  the  initial 
functional  requirements  can  be  examined  and  the  comparable 
existing  systems  which  come  closest  to  meeting  these 
functional  requirements  can  be  identified.  Design,  task, 
and  training  information  on  these  systems  can  then  be 
collected  and  modified  to  reflect  the  projected  system 
requirements.  Tre  outputs  of  these  design,  task,  and 
training  program  analyses  can  be  described  in  the  SDT.^ 
This  information  can  then  be  used  to  estimate  training 
resource  requirements.  This  initial  estimate  can  be  then 
compared  with  the  predecessor  system  to  indicate  how  the 
projected  system  fits  within  the  footprint  of  its 
predecessor.  If  a  specific  platform  (e.g.,  howitzer,  rocket 
launcher)  has  not  been  selected,  initial  training  estimates 
should  also  be  developed  for  each  platform  type  and  compared 
with  one  another  during  this  period. 


5  It  is  possible  to  input  contractor's  data  into  this 
estimation  process  in  a  step-by-step  manner  rather  than  wait 
until  the  contractor  studies  are  complete.  However,  such  an 
approach  runs  counter  to  the  current  practice. 
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It  should  be  noted  that  the  current  practice  is  not  to 
develop  any  systematic  estimates  of  training  resource 
requirements  during  this  period  but  to  wait  until  the 
contractors  have  completed  their  initial  studies  and  then 
have  experts  make  undocumented  estimations  of  the  general 
training  resource  requirements.  This  approach  overlooks  the 
fact  that  (1)  critical  design  questions  are  being  asked 
during  this  period  and  these  questions  require  training 
input  data  and  (2)  the  early  training  planning  process 
requires  a  solid  foundation  on  which  to  work  at  this  point. 

System  elements  should  not  be  described  at  a  low  level  of 
detail  at  this  point  in  the  acquisition.  This  means  that 
(a)  system  design  data  (1.2)  should  only  be  specified  down 
to  the  equipment  level  and  only  described  in  generic  terms 
(e.g.,  fire  control  computer),  (b)  task  data  (1.4)  should 
only  be  specified  down  to  the  task  level  and  only  specified 
for  those  systems  related  to  new  design  changes  (versus  the 
equipment  on  the  comparable  existing  system  from  which  it  is 
derived),  (c)  training  for  subsystems  not  related  to  new 
technologies  are  not  changed  unless  deficiencies  in  the 
current  training  program  are  identified,  (d)  only  general 
skill  and  knowledges  (1.4)  must  be  specified,  (e)  learning 
objectives  (i.6.2)  and  performance  (1.6.3)  and  ARTEP 
information  (1.6.5)  need  not  be  specified,  and  (f)  only 
general  training  media  (1.6.6)  requirements  must  be 
identified  since  the  major  emphasis  is  on  identifying 
expensive  media  (e.g.,  training  devices). 

•  Major  SDT  Applications  -  Documentation  and 
development  of  initial  design,  task,  skill,  and 
training  estimates?  provision  of  input  into 

training  planning  and  acquisition  documents? 
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provision  of  input  into  system  tradeoff  analyses; 
provision  of  input  into  evaluation  of  general 
training  alternatives;  and  provision  of  input  into 
contractor  studies  for  concept  investigation. 

2.4.3  Period  3:  Training  Estimation  for  Identified  Design 
Concepts 

This  period  covers  the  time  between  the  completion  of  the 
contractors'  initial  design  concept  studies  and  the 
development  of  initial  task  data  for  finals  which  have  been 
built  to  represent  these  design  concepts. 

The  application  of  the  SDT  during  this  period  is  similar  to 
the  application  of  the  SDT  during  Period  2  with  three  major 
exceptions.  First,  design  concepts  no  longer  have  to  be 
estimated  but  can  be  taken  directly  from  the  contractor 
reports.  Second,  and  most  important,  design,  task,  and 
skill  data  can  be  taken  to  a  lower  level  of  detail  and  thus 
more  detailed  estimates  of  training  program  elements  and 
training  resources  can  be  developed.  The  level  of  detail  to 
which  one  can  go  may  vary  from  subsystem  to  subsystem.  In 
general,  it  is  possible  to  go  to  lower  levels  of  detail  with 
systems  with  smaller  technological  change  than  with  systems 
associated  with  larger  technology  changes.  Third,  with  the 
formal  identification  of  design  conccspts,  greater  emphasis 
can  be  given  to  the  examination  of  training  alternatives 
(that  is,  of  alternative  ways  of  training  for  the  same 
tasks).  This  examination  of  training  alternatives  will  take 
place  during  Cost  and  Training  Effectiveness  Analyses 
(CTEA). 
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o  Major  SDT  Application  -  Documentation  of 
alternative  designs;  documentation  and  development 
of  task,  skill,  and  training  estimates;  provision 
of  input  into  training  planning,  training  analysis 
and  acquisition  documents;  provision  of  input  into 
system  tradeoff  analyses  and  evaluation  of 
alternative  designs;  provision  of  input  into 
evaluation  of  training  alternatives;  provision  of 
input  data  into  and/or  the  receipt  of  output  data 
from  ongoing  contractor  concept  development 
studies;  and  evaluation  of  impacts  of  design 
changes  within  each  design  alternative  on  tasks, 
skills,  and  training. 

2.4.4  Period  4:  Training  Estimation  for  Identified  Tasks 

This  period  encompasses  the  time  between  the  initial 
development  of  tasks  by  the  contractors  for  the  alternative 
design  concepts  and  the  development  of  training  program 
elements . 

•The  application  of  the  SDT  during  this  period  is  similar  to 
the  preceeding  period  with  three  major  exceptions.  First, 
task  data  no  longer  must  be  estimated  but  can  be  directly 
obtained  from  contractor  input  data.  Second,  design,  task, 
and  skill  data  can  be  taken  to  a  lower  level  of  detail 
permitting  more  detailed  estimates  of  training  program 
elements  and  resources.  Third,  more  specific  training 
alternatives  can  be  examined. 

•  Major  SDT  Applications  -  Documentation  of 
alternative  designs  and  their  associated  tasks; 
documentation  and  development  of  training  program 
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data;  provision  of  input  into  the  development  of 
criteria  for  evaluating  contractor  supplied  task 
data;  provision  of  input  into  training  planning 
and  acquisition  documents;  provision  of  input  into 
system  tradeoff  analyses  and  evaluation  of 
alternative  designs;  provision  of  data  for  the 
evaluation  of  detailed  training  alternatives; 
provision  of  data  to,  and/or  the  receipt  of  output 
data  from  ongoing  contractor  concept  development 
studies;  and  evaluation  of  the  impacts  of  design 
changes  within  each  design  alternative  on  tasks, 
skills,  and  training. 

2.4.5  Period  5:  Training  Development  for  Selected  System 

This  period  encompasses  the  time  between  the  initial 
development  of  training  data  for  the  selected  system  and  the 
completion  of  zhe  development  of  the  training  program  for 
that  system. 

The  period  differs  from  the  previous  period  in  three  major 
ways.  First,  as  the  period  progresses,  training  program 
data  need  no  longer  be  estimated — actual  training  program 
data  can  be  utilized.  Second,  task,  skill,  and  training 
data  must  be  carried  down  to  the  lowest  level  needed  for 
training  development.  The  SDT  data  elements  need  not  be 
described  at  these  lowest  levels;  however,  all  general  SDT 
data  elements  should  be  completed.  Third,  unlike  Period  2-4 
where  the  major  focus  of  the  SDT  was  on  the  provision  of 
information  for  training  estimation,  during  Period  5  the 
major  focus  of  the  SDT  is  on  data  base  management — that  is, 
keeping  track  of  minor  design  or  task  changes  and  their 
impacts  on  other  system  elements. 
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•  Major  SDT  Applications  -  Documentation  of  system 
design,  tasks,  skills,  and  training  program 
elements;  provision  of  criteria  for  evaluating 
input  into  the  development  of  contractor  training 
program  elements;  evaluation  of  the  impacts  of 
changes  of  one  system  element  on  other  system 
elements;  provision  of  input  into  training 
planning  and  acquisition  documents;  input  into  the 
evaluation  of  system  tradeoff  analyses;  and 
provision  of  input  into  the  evaluation  of  detailed 
training  alternatives. 

2.5  PAST  EFFORTS  IN  DEVELOPING  SYSTEM-SPECIFIC  DATA  BASES 


One  of  the  major  sources  of  information  which  was  utilized 
in  constructing  the  SDT  specifications  described  in  the 
previous  subsections  were  past  efforts  in  developing  system- 
specific  human  resource  data  bases.  Table  2-8  lists  the 
major  past  efforts  at  developing  human  resource  data  bases. 
These  efforts  are  reviewed  in  the  subsections  which  follow. 

2.5.1  Logistics  Support  Analysis  Record 

One  major  effort  which  is  closely  related  to  the  objectives 
and  goals  of  the  SDT  is  the  Logistics  Support  Analysis 
Record  (LSAR )  .  The  role  of  the  LSAR  in  the  acquisition 
process  is  discussed  in  Appendix  A.  MIL-STD-1388  states 
that  the  goal  of  the  LSAR  is  to  be  the  "single  source  of 
validated,  integrated  design-related  logistic  data  pertinent 
to  the  acquisition  program." 

Table  2-9  lists  the  system  elements  that  are  described  by 
the  LSAR  and  the  major  weaknesses  of  the  current  LSAR  in 
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Table  2-8 

PAST  EFFORTS  AT  HUMAN  RESOURCE  DATA  BASE  DEVELOPMENT* 

(1)  Logistics  Support  Analysis  Record  (LSAR) 

(2)  Unified  Data  Base  of  Air  Force  Human  Resource  Lab 

(3)  Consolidated  Data  Base  (CDB)  of  Navy/Army  HARDMAN  Projects 

(4)  Structured  Approach  to  Training  (SAT)  Program  for  the  B1  -Bomber 

(5)  Navy  Enlisted  Professional  Information  Support  System  (NEPl)ISS) 

♦Efforts  are  listed  in  terms  of  their  decreasing  relevance  to  the  ETES  SDT. 
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Table  2 -9 

OVERVIEW  OF  LSAR  AND  ITS  MAJOR  WEAKNESSES 


System  Elements  Described  by  LSAR 

•  Equipment  (work  breakdown  structure,  work  unit  code,  nomenclature, 
reliability,  maintainability,  failure  symptoms,  failure  effect  and  criticality, 
maintenance  concept) 

•  Tasks  (task  code,  frequency,  elapsed  time,  skill  specialty,  man  hours, 
requirements  for  training  equipment,  support  equipment,  tools,  task  elements, 
aggregate  maintenance  man-hour  requirements) 

•  Support  and  Test  Equipment  (physical  characteristics,  associated  equipment, 
associated  tasks,  associated  training,  special  skill  requirements) 

•  Facilities  (associated  equipment  and  tasks,  general  requirements,  ead 
times,  type  of  construction,  utilities,  facility  unit  cost) 

•  Skills  (associated  task  and  equipments,  specialty  codes,  aptitude,  rank/rate, 
special  physical  and  mental  requirements,  educational  requirements, 
additional  training  requirements) 

•  Supply  Support  (part  no.  and  nomenclature,  physical  description,  associated 
equipment,  allowance  quantity,  distribution) 


Major  Weaknesses  of  LSAR 

•  Does  not  describe  system  functional  requirements 

•  Does  not  provide  adequate  description  of  operator  tasks 

«  Does  not  describe  task  characteristics  or  performance  information 

•  Does  not  describe  collective  tasks 

•  Does  not  adequately  describe  skills 

•  Does  not  adequately  describe  training  program  elements 

•  Does  not  provide  mechanism  for  describing  estimated  or  projected  elements 

•  Is  not  applied  in  early  phases 

•  Does  not  have  data  base  management  capability 

•  Cannot  generate  tasks  or  other  input  data 


♦Many  of  these  limitations  arc  apparently  being  dealt  within  the  present  LSAR 
improvement  programs. 
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respect  to  the  goals  and  objectives  of  the  SDT .  As  Table  2- 
9  indicates,  the  LSAR  has  several  weaknesses  which  limit  its 
use  as  a  comprehensive  system  description  technology  for 
human  resource  assessment. 

First,  there  are  several  important  system  elements  (e.g., 
system  functional  requirements,  collective  tasks)  which  the 
LSAR  does  not  describe.  Failure  to  describe  the  system 
functional  requirements  is  particularly  distressing,  since 
these  functional  requirements  provide  the  foundation  on 
which  all  other  system  elements  depend.  Lack  of  a 
systematic  description  of  functional  requirements  makes  it 
extremely  difficult  for  training  developers  and  others  who 
are  tasked  with  relating  their  particular  system  elements  to 
overall  mission  performance  and  its  associated  functions. 
For  instance,  it  makes  it  extremely  difficult  to  relate 
human  tasks  to  mission  performance.  Given  its  lack  of  a 
capability  for  describing  system  functional  requirements  or 
projected  system  elements,  it  is  not  surprising  that  the 
LSAR  is  currently  not  applied  during  the  concept  exploration 
phase  of  the  acquisition  process  and  seldom,  if  ever, 
applied  during  the  validation  and  demonstration  phase. 
Hence,  its  value  as  a  data  base  to  support  early  human 
resource  assessment  is  very  minimal  indeed. 

Second,  there  are  a  number  of  other  systems  elements  which 
are  described  by  the  LSAR  but  are  not  described  adequately 
or  in  enough  detail  (e.g.,  operator  tasks,  task 
characteristics,  training  program  elements  skills).  The 
emphasis  of  the  LSAR  on  maintenance  assessment  and 
maintenance  tasks  is  quite  obvious.  This  emphasis  makes  it 
extremely  difficult  to  develop  or  maintain  adequate 
descriptions  of  operator  tasks.  For  all  types  of  tasks,  the 


2-46 


LSAR  does  not  fully  describe  the  task  characteristics  and 
performance  information  that  is  needed  by  training  and/or 
human  factors  specialists  to  adequately  assess  their 
components  of  the  system.  The  training  portion  of  the  LSAR 
places  an  emphasis  on  training  equipment  and  devices  and 
ignores  other  important  aspects  of  the  training  program 
(e.g.,  learning  objectives). 

Third,  at  a  more  conceptual  level,  the  LSAR  does  not  provide 
an  adequate  capability  for  describing  estimated  or  projected 
system  elements.  Such  estimates  are  necessary  during  the 
early  phases  of  the  acquisition  process. 

Fourth,  the  LSAR  was  not  conceived  as  an  automated  data  base 
management  system  for  system  description  --  that  is,  as  an 
automatic  system  for  describing,  updating,  and  expanding 
system  concepts  and  communicating  this  information  to  system 
users.  It  should  be  noted  that  the  Army,  through  the  DARCOM 
Materiel  Readiness  Support  Activity,  has  been  a  leader  in 
"automating  the  LSAR".  However,  this  automation  apparently 
refers  only  to  the  use  of  computerized  algorithms  for 
aggregating  certain  LSAR  elements  or  for  presenting  printed 
outputs  of  reports.  It  is  not  designed  to  be  an  interactive 
system.  More  important,  the  automated  LSAR  does  not  provide 
for  the  automated  description  of  system  concepts,  updates, 
changes  and  expansions  through  a  comprehensive  data  base 
management  system.  This  is  due  to  the  fact  that  the  LSAR 
does  not  have  a  systematic  internal  structure  linking  the 
various  system  elements  to  one  another. 


2.5.2  Air  Force  Human  Resources  Lab  Unified  Data  Base 

The  Air  Force  Human  Resource  Lab  ( AFHRL)  has  initiated  a 
program  to  develop  a  Unified  Data  Base  (UDB) .  The  goals  of 
the  UDB  are  very  similar  to  the  SDT  (see  Thomas,  Newhouse 
and  Hankins,  1980?  Thomas  and  Hankins,  1980).  Ultimately, 
the  UDB  is  designed  to  provide  "a  centrally  located  data 
base  of  human  resource-related  information  for  utilization 
in  the  weapon  system  acquisition  process  to  influence 
hardware  concepts  and  design".  The  UDB  is  to  be  supported 
by  a  Data  Generating  Technology  Data  Base  ( DGTB)  which  is 
intended  "to  generate  generic  data  to  fill  in  the  needs  of 
users  where  the  data  systems,  and  likewise  the  UDB,  would 
leave  voids."  Thus,  the  DGTB  is  somewhat  similar  to  the 
ETES  training  estimation  aids  and  procedures. 

To  date,  past  efforts  on  UDB  development  have  focussed  on 
(1)  an  assessment  of  existing  historical  data  bases  which 
would  feed  the  UDB,  particularly  the  projected  portions  of 
the  UDB,  (2)  a  description  of  the  weapon  system  design 
process  with  respect  to  the  potential  use  of  the  UDB,  (3)  an 
assessment  of  user  needs  in  terms  of  adequacy  of  current 
technology  and  data**,  and  (4)  the  development  of  a  plan  for 
UDB/ DGTB  development. 

At  the  present  time,  a  description  of  the  actual  data 
elements  to  be  included  in  the  UDB  is  not  available  (this  is 


6  In  the  examination  of  the  utilization  of  human  resource 
data  in  tradeoffs,  it  is  interesting  to  note  that  lack  of 
information  and  lack  of  appropriate  analytical  tools  were 
seen  as  two  of  the  major  types  of  limitations  on  the  use  of 
human  resource  assessment. 
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to  be  developed  in  future  phases  of  the  study).  However,  by 
examining  the  types  of  historical  data  bases  which  are  pro¬ 
jected  to  be  used  by  the  UDB,  it  is  possible  to  make  some 
estimates  of  what  it  will  contain  and  to  assess  some  of  its 
potential  '‘limitations . "  These  "limitations"  point  out  the 
differences  between  the  UDB  and  the  ETES  SDT.  These  dif¬ 
ferences  are  actually  quite  significant  despite  the  simil¬ 
arity  in  the  goals  of  these  two  systems  (see  Table  2-10). 

The  first  limitation  of  the  UDB  is  its  emphasis  on 
maintenance  tasks  and  personnel.  The  UDB,  like  the  Air 
Force  Coordinated  Human  Resources  Technology,  emphasizes 
maintenance  behavior  and  the  use  of  historical  data  bases 
related  to  maintenance.  There  is  little  relevant  discussion 
of  the  procedures  and  mechanisms  for  developing  or 
describing  operator  tasks  or  training  requirements. 

This  emphasis  on  maintenance  tasks  is  closely  related  to  a 
second  "limitation"  of  the  UDB;  namely,  its  emphasis  on 
aircraft  systems  and  on  Air  Force  data  bases.  In  the  Air 
Force,  the  role  of  enlisted  operators  is  much  less 
significant  than  it  is  in  the  Army  or  Navy.  Hence,  it  is 
not  surprising  that  the  UDB  has  focused  on  the  maintenance 
of  aircraft  systems. 

Third,  there  are  numbers  of  other  system  elements  which  the 
UDB  would  appear,  at  least  at  the  present  time,  not  to 
describe.  These  elements  include  functional  requirements, 
collective  or  team  tasks,  task  characteristics,  and 
performance  data  suitable  for  training  and  human  factors 
analytical  activities,  and  training  program  elements.  (This 
failure  to  describe  certain  elements  would  not  be  critical 
if  the  UDB  had  the  proper  data  base  management  structure  to 
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Table  2-10 

LIMITATIONS  OF  THE  UDB 


•  Focusses  almost  exclusively  on  maintenance  tasks 

•  Emphasizes  aircraft  systems 

•  Does  not  appear  to  adequately  describe  functional  requirements, 
collective  or  team  tasks,  task  characteristic  or  performance  data, 
and  training  program  elements 

•  Is  not  based  upon  comprehensive  data  base  management  system  or 
structure 

•  Is  geared  for  use  by  sophisticated  users 

•  Cannot  generate  tasks  and  other  input  data 
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handle  additional  system  elements.  Unfortunately,  it 
appears  that  it  does  not  have  this  capability). 

Fourth,  and  perhaps  most  important,  the  UDB  again  does  not 
appear  to  be  based  upon  a  data  base  structure — that  is,  a 
structure  wmcn  repiesentb  inc  ic luLicnchipc  among 

the  various  system  elements.  Such  a  data  base  management 
structure  would  provide  a  mechanism  for  describing  the  basic 
structure  of  a  developing  system  which  was  independ*  nt  of 
the  various  user  viewpoints  of  the  data.  This  data 
independence  would  increase  the  capability  for  relating 
various  descriptions  of  the  system  to  one  another,  for 
updating  and  refining  the  data,  and  for  adding  new  elements 
to  the  data  base  in  a  systematic  modular  fashion  with 
minimum  destruction  of  existing  programming — thus  providing 
tie  basis  for  a  true  data  base  management  capability. 

Fifth,  the  UDB  appears  to  be  geared  for  use  by  technical 
personnel  who  have  sophisticated  analytical  and/or  computer 
programming  experience — unlike  the  SDT  which  is  geared  for 
use  by  personnel  with  little  background  in  computers. 
Because  of  this  difference  in  emphasis,  it  is  not  surprising 
that  the  UDB  does  not  specify  or  deal  with  the  human  factors 
of  man-computer  interactions  as  will  the  SDT,  which  will  be 
specifically  geared  for  utilization  by  uninitiated  users  and 
will  attempt  to  employ  the  latest  guidelines  on  human- 
computer  interfaces  (see  Appendix  D).  Because  of  its  lack 
of  consideration  of  hun.^n  factors  issues,  the  UDB  does  not 
attempt  to  provide  procedures  for  assisting  the  user  in 
generating  tasks  or  other  input  data  elements. 
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2.5.3  Consolidated  Data  Base  (CDB )  of  HARDMAN  Methodology 


The  Navy  has  a  program,  called  the  HARDMAN  program  (hardware 
versus  manpower  procurement),  to  develop  a  methodology  to 
systematically  assess  the  manpower,  personnel,  and  training 
requirements  of  emerging  weapons  systems,  with  particular 
emphasis  on  developing  predictions  roi  die  cai 1*  of 
the  acquisition  process.  The  HARDMAN  methodology  has  been 
applied  to  a  number  of  different  Navy  systems  and  has  been 
modified  for  use  by  the  Army  and  applied  to  the  Enhanced 
Self-Propelled  Artillery  Weapon  System  (ESPAWS)  (see 
Dynamics  Research  Reports  1980a,  1980B,  and  Mannle  1980  for 
a  discussion  of  HARDMAN). 

The  application  of  the  HARDMAN  methodology  is  supported  by 
the  development  of  a  system-specific  "data  base"  which  is 
designed  to  contain  all  of  the  inputs  and  outputs  of  each  of 
the  steps  in  the  HARDMAN  methodology  and  provide  an  audit 
trail  for  monitoring  the  data  elements  which  are 
developed.  Table  2-11  lists  the  data  elements  described  by 
the  CDB. 

Like  the  other,  current  human  resource  data  bases,  the  CDB 
has  several  limitations  with  respect  to  the  SDT 
requirements . 

The  major  limitation  of  the  CDB  is  that  only  parts  of  it  are 
automated.  Thus,  it  can  not  provide  a  computerized  data 
base  management  capability.  Another  major  limitation  of  the 
CDB  is  that,  like  the  UDB,  it  does  not  contain  a  systematic 
scheme  for  relating  the  various  system  elements  to  one 
another,  a  scheme  which  would  be  independent  of  specific 
input  and  output  requirements.  Thus,  the  CDB  is  not  really 
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Table  2-11 

DATA  ELEMENTS  CONTAINED  IN  CDB 


General  System 

•  Requirements  Documents 

•  Study  Plans  and  Objectives 

•  Technology  Base  Studies 

,  ProWtpr!  Onprfltinnfll  Environment 

•  System  Functions  and  Performance  Requirements 

•  Program  Constraints 

•  Minimal  Essential  Elements  of  Information  List 

•  Audit  Trail  Files 

•  Worksheets 

•  CDB  Index 

•  Predecessor  Equipment  List  and  Related  Data 

•  Reference  Equipment  List  and  Related  Data 

•  Predecessor  and  Reference  Reliability  Data 

Manpower* 

•  Workload  Taxonomy 

•  Indirect  Workload  Factors 

•  Task  Event  Networks 

•  Manpower  Model  Data 

•  Manpower  Metrics  and  Associated  Values 

•  System  Manning  (MOS,  Skill  Level,  Duty  Positions) 

Training* 

•  Task  and  Skill  Data 

•  Course  Catalogue 

•  Course  Outlines 

•  Course  Methods/Media 

•  Course  Costing  Data 

0  Course  Scenario  Information 

0  Career  Path  Information 

0  Training  Concept 

0  Training  Device  and  Equipment 
0  Steady  State  Resource  Requirements 

0  Steady  State  Course  Costs 

0  Replacement  Personnel  Requirements 
0  Task  Selection  and  Assignment  Algorithms 
0  Facilities  Requirements 

Personnel* 

0  Career  Path  Data 

0  Career  Path  Statistics  (Attrition,  Promotion,  Upgrade) 


♦All  elements  for  predecessor,  reference,  and  baseline  systems  except  where  noted. 
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a  true  data  base  management  system  since  it  does  not  have  an 
automated  capability  for  linking  various  system  elements  to 
another  or  for  retrieving  data  elements. 

Finally,  the  CDB  does  not  provide  any  extensive  automated 
nanahi 1 itiPR  for  aeneratina  input  data  formats  or  actual 
input  data  elements. 

2.5.4  SAT  Program  for  the  B-l  Bomber 

The  Structural  Approach  to  Training  (SAT)  program  for  the  B- 
1  bomber  represents  a  relatively  early  attempt  to  develop  a 
system-specific  data  base  to  support  instructional  systems 
development  (see  Sugarman,  Johnson  and  Ring,  1975). 

The  SAT  consisted  of  two  major  elements,  a  data  base  (the 
contents  of  which  are  displayed  in  Table  2-12)  and  two 
computerized  aids  —  one  aid  is  a  sortinq  model  for  the 
storage,  retrieval,  collating,  and  updating  of  mission/ 
function  task  analyses  and  supporting  data;  and  the  other  is 
an  analytical  model  for  providing  cost  and  training 
estimates  of  the  B-l  bomber  training  system. 

The  SAT  data  base  is  interesting  in  that  it  is  probably  the 
only  past  effort  which  has  attempted  to  (1)  systematically 
describe  task  characteristics  in  a  format  which  is  amenable 
to  the  application  of  automated  training  aids  for 
determining  the  tasks  to  be  trained  and  selecting  methods 
and  media,  and  (2)  systematically  describe  the  task 
performance  characteristics  of  equipment  (e.g.,  relation¬ 
ships  of  tasks  to  controls  end  displays).  Such  task 
performance  data  is  critical  to  human  task  performance 
simulation  models.  The  SAT  also  had  a  number  of  other 
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Table  2-12 

SAT  DATA  ELEMENTS  AND  LIMITATIONS 


System  Elements  Described  by  SAT  Data  Base 

•  Tasks  (title,  task  element  number,  operator  behavior,  task  duration, 
crew  interaction,  previous  task  element,  task  characteristics,  and 
performance  data) 

•  Control/display  information  (associated  system,  synonyms) 

•  Behavioral  objectives  (title,  initial  conditions,  concurrent  behaviors, 
performance  criteria,  enabling  and  ancillary  objectives,  operators, 
interactions,  task  elements,  objective  criticality,  objective  difficulty) 

Limitations  of  SAT  Data  Base 

•  Is  geared  for  one  specific  system 

•  Is  not  designed  to  provide  generic  data  base  management  capability 

•  Does  not  systematically  describe  system  functional  requirements  and 
design  concepts 

•  Does  not  include  training  program  elements  in  automated  portion 
of  the  data  base 

•  Is  geared  for  sophisticated  users 

•  Cannot  generate  tasks  and  other  input  data 
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interesting  features,  such  as  a  task  action  verb  dictionary 
which  listed  task  synonyms. 

However,  despite  its  desirable  features  the  SAT  data  base 
also  has  several  limitations  which  restrict  its  applic¬ 
ability  to  the  SDT .  First,  the  SAT  data  base  elements  and 
programs  were  specifically  designed  to  fit  one  system — the 
B-l  bomber.  Thus,  all  of  its  task  and  control /display 
dictionaries  and  structures  are  only  applicable  to  that 
system.  The  SAT  was  not  designed  to  be  a  generic  data  base 
system  which  could  be  applied  across  a  wide  range  of  weapon 
systems . 

Second,  the  SAT  does  not  describe  several  important  system 
elements  such  as  functional  requirements  and  design/hardware 
elements . 

Third,  training  program  elements  are  described  but  not 
included  in  the  automated  data  base. 

Fourth,  the  SAT  is  geared  for  very  sophist icated  users  with 
extensive  computer  experience. 

Fifth,  the  SAT  is  not  structured  to  assist  users  in 
developing  input  data  formats  or  actual  input  data  elements 
such  as  tasks. 

2.5.5  Navy  Enlisted  Professional  Development  information 
Support  System  (NEPDISS) 

The  objectives  of  the  NEPDISS  are  more  limiteu  than  the 
goals  of  the  other  human  resource  data  bases  described 
above.  The  NEPDISS  is  specifically  designed  to  store  and  . 

retrieve  data  related  to  training  program  development  (see 
Davis,  1977,  for  a  description).  Thus,  it  is  primarily 
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designed  to  describe  task  and  training  data  (see  Table  2- 
13).  Its  only  description  of  equipment-related  concepts  is 
in  the  task  statements  of  the  task  portion  of  the  data 
base.  Other  major  limitations  of  the  NEPDISS  are  its  lack 
of  capability  for  describing  projected  system  elements,  its 
total  lack  of  appropriateness  for  use  by  uninitiated  users, 
its  lack  of  a  capability  for  generating  tasks  and  other  data 
impacts,  and  most  important,  its  lack  of  a  true  data  base 
management  capability  for  updating  and  refining  system 
elements . 

Despite  the  weaknesses,  it  is  important  to  note  that  the 
NEPDISS  is  especially  strong  in  describing  task  and  skill 
related  requirements  which  are  appropriate  for  training  and 
personnel  analysis. 

2.5.6  Other  Data  Bases 

There  are  a  number  of  other  data  bases  which  attempt  to  deal 
with  some  of  the  issues  related  to  the  SDT .  For  instance, 
the  Consolidated  Occupational  Data  Analysis  Program  (CODAP) 
and  the  Training  Developments  Information  System  (TDIS)  are 
Army  data  bases  which  also  deal  with  task  description.  The 
CODAP  focusses  on  tasks  from  the  perspective  of  a  single  MOS 
while  the  TDIS  focusses  on  common  tasks  which  are  applicable 
across  MOS.  Neither  one  is  geared  for  use  in  describing  the 
design,  task,  and  training  characteristics  of  an  emerging 
weapon  system.  Nevertheless,  the  aspects  of  these  systems 
which  are  relevant  to  the  SDT  (primarily  the  task 
descriptions)  were  examined  in  detail  during  the  development 
of  the  SDT  specifications  and  these  systems  will  continue  to 
be  monitored  as  the  SDT  is  developed. 
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Table  2-13 


NEPDISS  DATA  LIMITATIONS 

•  Does  not  describe  system  functional  requirements,  design  concepts,  training 
program  elements  or  collective  tasks. 

•  Is  geared  for  use  by  sophisticated  users. 

•  Cannot  generate  task  and  other  input  data. 

•  Is  not  designed  to  describe  projected  system  elements. 

•  Does  not  provide  comprehensive  data  base  management  capability  for  updating 
and  refining  system  elements. 
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SECTION  3  -  SELECTION  OF  AN  AUTOMATED  TOOL 
FOR  SDT  DEVELOPMENT 


This  section  presents  the  resalts  of  a  review  of  automated 
tools  which  were  considered  as  possible  vehicles  tor  the 
development  of  the  SDT.  The  chapter  is  divided  into  six 
sections.  The  first  section  presents  an  overview  of  the 
different  types  of  automated  tools  which  were  examined 
during  the  review.  The  next  two  sections  present  the 
results  of  a  review  of  two  different  classes  of  automated 
tools:  requirements  analysis  tools  and  data  base  management 

systems.  The  final  three  sections  evaluate  database 
management  systems  and  select  a  database  management  system 
suitable  for  SDT  development,  implementation,  and  operation. 

3.1  OVERVIEW  OF  AUTOMATED  TOOLS 

The  central  need  for  early  training  estimation  is  a 
systematic  method  of  communicating  weapon  system  information 
to  the  participants  in  the  acquisition  process  (e.g.: 
training  developers,  combat  developers,  materiel  developers, 
etc.).  These  participants  are  generally  uninitiated  in  the 
use  of  computer  equipment  and  systems.  With  this  focus,  two 
major  classes  of  automated  tools  were  examined  during  Task 
1:  requirements  analysis  tools  and  data  base  management 

systems.  The  review  began  with  an  examination  of 

requirements  analysis  tools  and  was  completed  with  the 
review  of  data  base  management  systems. 


As  more  and  more  data  was  obtained  on  the  current  procedures 
and  problems,  and  available  tools  were  examined  in  detail,  a 
firm  picture  of  the  requirements  for  the  SDT  developed.  It 
was  determined  that  a  data  base  management  system  was  the 
tool  which  could  best  meet  the  SDT  requirements  (see  Section 
2  for  a  description  of  the  SDT  specifications  and  Section  4 
for  a  description  of  a  final  SDT  which  incorporates  many  of 
the  data  base  management  system  concepts  discussed  in  this 
chapter) . 

3.2  REVIEW  OF  REQUIREMENTS  ANALYSIS  TOOLS 

The  review  of  requirements  analysis  tools  was  conducted  in  a 
three-stage  process  by  DRC ' s  software  engineering  group. 
During  the  first  stage,  DRC  surveyed  government  reports, 
IEEE  Software  Engineering  Transactions,  and  other  trade 
publications  to  determine  what  tools  were  available  in  the 
area  of  requirements  analysis.  Fortunately,  a  comprehensive 
review  of  requirements  analysis  tools  had  just  been 
completed  by  Devorkin  and  Obenodorf  (1979).  Further 
investigation  indicated  that  this  report  contained  all 
requirements  analysis  tools  with  sufficient  maturity  for 
possible  use  in  the  SDT. 

During  the  second  phase  of  the  review,  the  methodologies 
listed  in  Devorkin  and  Obendorf  were  reviewed  in  more 
detail.  Each  review  began  with  an  examination  of  the 
available  literature  on  the  methodology.  Following  the 
literature  review,  individual  users  were  interviewed  by 
phone.  With  the  aid  of  user  comments  and  knowledge  of  the 
SDT  requirements,  criteria  were  developed  for  identifying 
methodologies  with  a  high  degree  of  potential  application  to 
the  SDT.  The  evaluation  criteria  were  as  follows: 
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1.  Applicability 

The  methodology  must  be  capable  of  building  a  data 
base  of  the  conceptual  information  normally 
available  during  the  early  phases  of  a  developing 
or  evolving  system.  This  data  base  must  be 
capable  of  refinement  as  more  specific  system 
information  becomes  available.  It  must  be  capable 
of  describing  requirements,  design  concepts,  human 
tasks,  and  training  program  elements. 

2.  Understandabi lity 

The  methodology  must  be  capable  of  being 
understood  by  the  types  of  “personnel"  who  are 
likely  to  use  the  SOT. 

3.  Demonstratability 

The  methodology  must  have  been  applied  to  a  number 
of  different  types  of  projects. 

4.  Transportability 

The  methodology  must  be  capable  of  being 
implemented  at  a  minimum  of  cost  on  standard 
business  processors  used  in  mi 1 i t ary/government 
agencies . 

5.  Training 

The  methodology  must  have  an  existing  formal 
training  program  available  to  the  user. 

6.  Sponsorship 

The  methodology  must  have  a  specific  government 
agency,  university  or  industry  committed  to 
enhancing  the  methodology  to  meet  additional  user 
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needs  as  they  become  known.  The  methodology  must 
reside  in  the  public  domain. 

While  investigating  the  first  few  methodologies,,  it  Became 
evident  that  there  were  two  main  thrusts  in  the  area  of 
requirements  ue£iiiicicm  mcujuuoioyitia.  thrust 
emphasized  graphics  representation,  primarily  through 
functional  flow  block  diagrams,  as  a  means  of  specifying 
relationships  between  system  elements.  Another  thrust 
emphasized  a  high  level  conceptual  language  as  the  mechanism 
for  specifying  relationships  between  these  system 
elements.  Because  there  was  a  good  de* 1  of  overlap  between 
the  tools  within  each  of  these  two  thrusts,  particularly 
among  the  language-based  tools  which  are  all  basically  more 
advanced  derivatives  of  earlier  work  conducted  by  the  ISDOS 
project  at  the  University  of  Michigan,  it  was  decided  that 
the  tools  listed  in  Devorken  and  Obendorf  would  be  evaluated 
in  terms  of  the  six  criteria  listed  above,  and  that  the  tool 
in  each  of  the  two  major  thrust  areas  with  the  highest 
evaluations  on  these  criteria  would  be  selected  for  further 
analysis  in  the  third  stage  of  the  review. 

Table  3-1  displays  the  requirements  analysis  tools  which 
were  evaluated  during  this  stage  and  summarizes  their 
assessment . 

The  two  tools  selected  for  further  analysis  were  the  ICAM 
Definition  Language  or  IDEF,  which  was  determined  to  be  the 
best  graphics  based  tool,  and  the  Problem  Statement 
Language/Problem  Statement  Analyzer,  which  was  selected  as 
the  best  language  based  tool.  During  the  third  stage  of  the 
review,  these  two  tools  were  examired  in  even  greater 
detai l . 
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AUTOIDEF 


The  IDEF  tool  was  developed  by  the  Air  Force's  Integrated 
Computer-Aided  Manufacturing  (ICAM)  Project  Office.  IDEF 
was  originally  developed  to  describe  the  "Architecture  of 
Manufacturing"  for  an  idealized  computer  aided  manufacturing 
plant.  The  IDEF  format  is  very  similar  to  the  Structured 
Analysis  and  Design  Technique  (SADT)  developed  by  Softech, 
Inc.  and,  in  fact,  is  derived  from  it. 

The  IDEF  had  several  advantages  over  other  tools  which  were 
readily  apparent.  First,  the  ICAM  project  office  has  a 
long-term  commitment  to  continuing  to  develop  IDEF  as  new 
needs  are  uncovered.  Second,  IDEF  was  recently  automated  in 
a  version  called  AUTOIDEF.  Before  this  automated 

capability,  the  IDEF  tool  had  no  real  capability  for 
automatic  storage,  update,  and  retrieval  of  the  diagrams 
which  are  its  major  mechanism  for  describing  information. 
Thus,  without  this  automated  capability,  IDEF  would  not 
merit  even  initial  consideration  as  a  SDT  vehicle.  Third, 
AUTO  IDEF  is  supported  by  a  software  package  developed  on 
Wright  Patterson's  CDC  processor.  Fourth,  it  has  been 
extensively  applied  within  the  ICAM  project. 

To  examine  AUTOIDEF  in  greater  detail,  URC  (1)  interviewed 
several  users,  (2)  obtained  and  examined  in  detail  AUTOIDEF 
user  manuals,  (3)  obtained  the  source  code  and  determined 
what  it  would  take  to  transport  the  system  to  a  non-CDC 
processor,  and  (4)  obtained  a  hookup  to  the  Wright-Patterson 
computer  and  attempted  to  utilize  AUTOIDEF  to  describe  SDT- 
related  elements  for  a  dummy  example.  The  results  of  the 
detailed  examination  were  not  encouraging.  First,  it 
appeared  that  in  its  current  state,  the  AUDOIDEF  is 
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difficult  to  use  and  requires  a  fairly  long  time  (one  half 
hour)  to  develop  a  single  functional  flow  diagram.  In 
addition,  the  IDEF  does  not  appear  to  be  a  tool  which  is 
appropriate  for  uninitiated  users,  since  it  requires 

learning  a  relatively  complex  command  language  (by  SDT 
standards),  and  is  geared  for  users  with  an  existing 
computer  background. 

•  PSL/PSA 

PSL/PSA,  like  two  other  major  language  based  tools,  the 
Computer-Aided  Design  and  Specification  Tool  (CADSAT)  and 
the  Software  Requirements  Engineering  Methodology  (SREM), 
was  derived  from  initial  work  done  at  the  University  of 

Michigan  ISDOS  project.  PSL/PSA  was  chosen  over  the  other 
tools  for  the  stage  three  review  because  it  has  had  wider 
usage,  has  several  sponsors  (University  of  Michigan  and  the 
PSL/PSA  Users  Group)  committed  to  fund  continuing 
development,  and  has  a  fully  developed  training  program. 

To  examine  the  PSL/PSA  in  more  detail,  DRC  (1)  obtained  and 
examined  the  user  manuals,  (2)  determined  what  it  would  cost 

to  purchase  usage  of  the  PSL/PSA,  and  (3)  sent  several 

members  of  its  software  engineering  group  to  a  PSL/PSA 
course  to  see  first-hand  what  actual  PSL/PSA  applications 
looked  like.  Unfortunately,  as  with  IDEF,  the  results  were 
not  encouraging.  PSL  is  a  fairly  abstract  language  that  is 
beyond  the  capabilities  of  the  uninitiated  user  who  is 
expected  to  utilize  the  SDT.  In  addition,  the  documentation 
fo  PSL/PSA  is  oriented  to  the  technical,  rather  than  the 
unitiated,  user. 
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•  Summary  of  Review  of  Requirements  Analysis  Tools 

In  summary,  current  requirements  tools  do  not  appear  to  be 
suited  for  the  types  of  uninitiated  users  who  will  utilize 
the  SDT .  This  is  not  surprising  when  one  considers  that  all 
of  these  tools  were  specifically  designed  to  describe 
software  requirements  for  large  complex  systems.  Hence, 
they  are  designed  to  be  utilized  by  technical  personnel  who 
have  fairly  sophisticated  backgrounds  in  computers.  (The 
tools  were  designed  by  software  specialists  for  software 
specialists . ) 

At  a  slightly  more  conceptual  level,  another  factor 
contributing  to  the  complexity  of  the  requirements  analysis 
tools  is  that  they  are  designed  to  be  extremely  flexible 
tools  which  can  be  utilized  to  describe  any  type  or  system. 
This  type  of  flexibility  necessitates  a  certain  degree  of 
abstractness.  This  high  degree  of  flexibility  and  its 
associated  abstractness  may  actually  be  a  hindrance  in 
describing  the  elements  of  the  weapons  systems  in  the  SDT. 
(A  descriptions  of  these  elements  is  contained  in  Section  2 
and  subsection  3.5.) 

Finally,  it  should  be  noted  that  while  requirements  analysis 
tools  deal  with  an  important  aspect  of  early  training 
estimation  (i.e.,  system  description),  they  are  not  really 
geared  for  dealing  with  other  important  ETES  related 
problems?  namely,  the  update  and  refinement  of  these  system 
descriptions  and  their  communication  to  a  wide  range  of 
participants  in  the  acquisition  process. 
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3.3  REVIEW  OF  DATA  BASE  MANAGEMENT  SYSTEMS 


Data  Base  Management  Systems  (DBMSs)  were  reviewed  next. 
Generally,  DBMSs  fulfill  the  SDT  evaluation  criteria  of 
applicability,  understandability,  demonstratability, 

transportability,  training,  and  sponsorship  that  were 
identified  in  Section  3.2.  In  addition,  most  DBMSs  have  the 
following  advantages  for  the  SDT: 

1.  The  DBMSs  are  designed  to  store  many  data  items 
chat  are  related  to  one  another.  The  SDT  consists 
of  many  data  items  with  complex  interrelation¬ 
ships.  Therefore,  DBMS  technology  facilitates  the 
development  of  the  SDT. 

2.  Data  is  centrally  located  and  controlled.  This 
simplifies  data  sharing  among  multiple  users. 

3.  They  can  be  fitted  with  data  access  aids  that  are 
easy  to  use.  These  aids  allow  a  user  to  input, 
modify,  delete,  and  output  data  using  English-like 
phrases  and  commands. 

4.  Access  to  data  items  can  be  restricted. 
Unauthorized  users  cannot  view,  modify,  delete,  or 
output  restricted  data  items. 

5.  They  can  be  structured  to  present  each  user  with  a 
different  view  of  specific  data  within  the  data 
base.  In  other  words,  each  user  can  be  presented 
with  data  in  a  format  that  is  meaningful  to  him 
alone. 
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6.  The  format  of  a  data  item  is  independent  of  the 
computer  program  that  is  accessing  it.  This  is 
significant  if  future  software  systems — other  than 
the  SDT — wish  to  access  the  data  in  the  SDT  data 
base.  The  development  of  this  interface  is 
simplified. 

7.  Standards  can  be  enforced  on  data  items  and  on 
their  physical  storage  in  the  data  base. 

3.3.1  Overview  of  Data  Base  Management  Systems 

Before  proceeding  to  examine  DBMSs  from  an  SDT  perspective, 
it  may  be  useful  to  review  exactly  what  a  DBMS  is.  This 
will  be  accomplished  in  a  two-step  fashion  by  first  defining 
what  a  "data  base"  is  and  then  outlining  the  essential 
features  of  a  data  base  management  system. 

3. 3. 1.1  "What  is  a  Data  Base?" 

An  automated  data  base  may  be  defined  as  a  computerized  and 
integrated  collection  of  stored  operational  data  used  by  the 
applications  groups  of  a  particular  enterprise.1  The  key 
word  in  this  definition  is  "integrated."  The  data  elements 
of  a  system  are  likely  to  have  relationships  or  associations 
which  one  could  use  to  link  these  elements  to  one  another. 
A  data  base  is  integrated  when  it  incorporates  information 
on  these  relationships  well  as  information  on  the  data 

elements  themselves.  This  information  can  be  used  to  store 


1  This  definition  is  a  modification  of  an  existing 
definition  by  F.ngels  (1971) 
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and  retrieve  data.  It  should  be  noted  that,  strictly 
speaking,  a  data  base  need  not  be  resident  in  a  computer  or 
its  associated  media.  However,  all  automated  data  bases 
will  be  stored  on  a  computer  or  related  media  and  all  modern 
DBMSs  are  automated.  It  is  clear  that  only  an  automated 
data  base  can  meet  the  storage  and  retrieval  requirements  of 
the  SDT.  The  term  “operational  data"  is  used  to  refer  to 
data  which  is  pertinent  to  the  ongoing  activities  of  an 
enterprise.  Operational  data  excludes  input  data,  work 
queues,  output  data  (such  as  messages  or  reports)  or  any 
other  form  of  temporary  information. 

3.3. 1.2  Advantages  of  a  Data  Base 

The  major  advantage  of  a  data  base  is  that  it  provides  the 
enterprise  with  integrated,  centralized  control  of  its 
operational  data.  This  centralized  control  can,  in  turn, 
(1)  reduce  redundancy  in  stored  data,  (2)  avoid 
inconsistency  in  stored  data,  (3)  allow  for  greater  sharing 
of  data,  (4)  permit  standards  to  be  enforced,  (5)  permit 
security  restrictions  to  be  applied,  and  (6)  permit  a 
greater  capability  for  checking  and  maintaining  data.  If  a 
data  base  is  used  in  conjunction  with  a  DBMS  it  can  also 
provide  an  additional  advantage;  namely,  “data 
independence. “  Data  independence  is  achieved  by  maintaining 
an  internal  structure  of  the  data  which  is  independent  of 
the  individual  applications  of  the  data  and  individual  user 
viewpoints.  This  data  independence  may  be  contrasted  with 
data  dependent  systems  in  which  the  way  data  is  stored  and 
the  way  it  is  accessed  are  dictated  by  the  structure  of  the 
applications . 
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3. 3. 1.3  Data  Base  Management  System 


Perhaps  the  best  way  to  describe  the  essential  features  of  a 
DBMS  is  to  outline  an  "architecture”  for  a  typical  DBMS. 
Such  an  architecture  is  displayed  in  Figure  3-1.  This 
architecture  is  taken  directly  from  Date  (1977).  DBMS 
architectures  are  typically  divided  into  three  general 
levels:  internal,  conceptual,  and  external.  The  internal 

level  is  concerned  with  the  way  in  which  the  data  is 
actually  stored  physically.  The  external  level  reflects  the 
users'  views  of  the  data.  The  conceptual  level  provides  the 
medium  for  linking  the  internal  and  external  views.  The 
conceptual  model  provides  a  general  community  view  of  the 
data  base  since  it  contains  an  abstract  representation  of 
the  entire  data  base.  This  community  view  is  to  be 
contrasted  with  the  external  views  of  individual  users  who 
typically  will  only  have  a  view  of  a  portion  of  the  data 
base. 

Perhaps  another  way  to  describe  these  three  different  levels 
of  a  DBMS  is  to  refer  to  the  structures  that  psycholinguists 
use  to  describe  human  language.  The  external  view  of  a  DBMS 
con  be  construed  as  being  roughly  analogous  to  what 
psycholinguists  describe  as  the  "surface  structure"  of 
language,  while  the  conceptual  level  can  be  construed  as 
being  analogous  to  the  "deep  structure"  of  language  and  the 
internal  structure  can  be  construed  as  being  roughly 
analogous  to  the  physical  structures  in  the  brain  for 
representing  speech. 

It  is  possible  for  each  external  user  to  have  his  own 
"language"  for  utilising  the  data  base,  although  in  many 
cases  all  or  a  large  number  of  users  can  use  the  same 
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language.  (As  we  shall  see  in  the  description  of  the  final 
SDT  in  Section  4,  the  SDT  will  utilize  a  single  language  for 
all  users.)  A  subset  of  a  user's  language  must  include  the 
data  sublanguage  for  storing  and  retrieving  information. 
Each  user  may  have  a  workspace  for  receiving  and 
transmitting  data  transferred  between  the  user  and  the  data 
base. 

The  conceptual  model  is  defined  by  a  conceptual  schema  which 
includes  a  definition  of  each  of  the  various  types  of 
conceptual  information  in  terms  of  content  only  (storage  or 
access  features  are  not  described).  Thus,  the  conceptual 
model  provides  the  definition  of  the  total  data  base 
content.  The  conceptual  model  is  critical  in  that  all  other 
aspects  of  the  DBMS  are  affected  by  the  conceptual  model. 
It  has  a  major  effect  on  the  format  and  structure  of  the 
data  sublanguage  which  is  used  to  store,  update,  and 
retrieve  information  from  the  data  base. 

3.3.2  Types  of  Data  Base  Management  Systems 

Data  Base  Management  Systems  can  be  categorized  by  the  type 
of  conceptual  model  they  employ  to  define  their  data  base 
structure.  There  are  three  general  categories:  the 
relational  approach,  the  hierarchical  approach,  and  the 
network  approach.  More  details  on  these  three  approaches  are 
presented  in  the  sections  which  follow. 

3. 3. 2.1  Relational  Data  Bases 

An  example  of  a  relational  model  is  contained  in  Figure  3- 
2t  Each  row  in  the  table  can  be  described  as  an  entity 
while  the  columns  can  be  described  as  attributes.  Each 
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FIGURE  32  RELATIONAL  OBMS  FORM 


table  represents  a  series  of  relationships  between  entities 
and  between  entities  and  attributes.  A  crucial  feature  of  a 
relational  data  structure  is  that  associations  between  rows 
or  entities  are  represented  solely  by  the  data  values  in 
columns  drawn  from  a  common  domain.  It  is  characteristic  of 
the  relational  approach  that  all  information  in  the  data 
base,  both  entities  and  associations,  are  represented  in  a 
single  uniform  manner,  namely  tables.  This  uniformity  of 
data  representation  leads  to  a  corresponding  uniformity  and 
simplicity  in  the  commands  required  in  the  data  sublanguage 
to  utilize  a  relational  data  base  (e.g.,  delete). 
Therefore,  relationally  structured  data  bases  are  generally 
easy  to  understand  and  use. 

3. 3. 2. 2  Network  Approach 

The  network  approach  is  similar  to  the  hierarchical  approach 
in  that  it  has  several  different  types  of  records,  which  are 
associated  with  one  another  via  links  (Figure  2-3). 
However,  a  network  is  a  more  general  structure  than  a 
hierarchy  because  a  recoct  may  have  any  number  of  immediate 
superiors-unlike  the  hierarchical  approach  which  has  one 
superior.  The  network  approach  thus  makes  it  easier  to 
represent  many-to-many  correspondences  more  directly  than 
does  the  hierarchical  approach.  Therefore,  a  network 
structured  database  can  represent  "typical**  relationships 
among  data  items,  more  so  than  a  hierarchical  structure. 

3. 3. 2.3  Hierarchical  Approach 

Just  as  the  basic  model  underlying  the  relational  model  can 
be  represented  by  a  table,  the  hierarchical  model  can  be 
represented  by  a  tree  structure  (see  Figure  3-4).  The 
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hierarchical  model  can  be  described  as  a  single  file, 
containing  records  arranged  into  trees.  The  files  in  a 
hierarchical  approach  can  be  more  confusing  than  the  files 
in  a  relational  approach  because  (1)  they  contain  several 
different  types  of  records  and  (2)  they  contain  links 
connecting  occurrences  of  these  records.  A  fundamental 
aspect  of  the  hierarchical  approach  is  that  any  record 
occurrence  can  only  be  accessed  when  its  context  (that  is,  a 
record's  relationship  to  its  superior)  is  taken  into 
account. 

3.4  THE  APPLICATION  OF  DBMS  TECHNOLOGY  TO  THE  SDT 


Because  DBMS  technology  can  fulfill  the  requirements  of  the 
SDT  better  than  existing  requirements  analysis  tools,  the 
SDT  will  be  developed  using  a  DBMS. 

Selecting  a  DBMS  for  a  particular  application — such  as  the 
SDT — is  difficult.  Many  factors  affect  this  decision.  Some 
of  these  factors  are  the  following: 

•  Logical  structure  of  the  data  base  at  the 
conceptual  level, 

•  Specific  features  of  the  DBMS, 

•  Capabilities  of  supporting  facilities,  and 

•  Cost  of  the  DBMS  and  its  supporting  facilities. 

For  any  application,  a  DBMS  with  a  relational  structure  at 
the  conceptual  level  has  several  advantages.  First,  a 
relational  data  base  is  easy  to  develop  and  comprehend. 
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Therefore,  developing  software  systems  that  interact  with  a 
relational  data  base  is  less  complicated.  Second,  user 
access  to  data  items  is  simple.  Inquiries  and  retrievals 
are  conducted  through  tables  of  related  data  items.  Third, 
this  structure  facilitiates  access  to  both  individual  data 
items  and  groups  of  data. 

User  interaction  with  a  relational  DBMS  may  be  slower.  This 
is  because  the  relational  DBMS  software  performs  more  tasks 
to  process  a  given  command  than  a  network  or  hierarchical 
DBMS.  Also,  relational  DBMSs  are  relatively  new  and  are  not 
as  developed  as  network  or  hierarchical  DBMSs. 

The  network  structure  reflects  real  world  situations  because 
it  may  be  accessed  from  any  point  within  the  data  base. 
Also,  this  structure  has  the  support  of  the  Conference  of 
Data  Description  Languages  (CODASYL)  Programming  Language 
Committee  (PLC)  Data  Base  Task  Group  ( DBTG ) ,  the  group  that 
proposed  standards  for  DBMS  programming  languages. 

The  representation  of  relationships  among  data  items  in  a 
network  data  base  may  be  complex.  This  can  complicate  the 
development  of  application  programs  that  interact  with  the 
DBMS. 

For  data  items  that  logically  fit  into  a  hierarchical 
structure,  a  hierarchical  DBMS  is  appropriate.  The 
structure  of  a  hierarchical  data  base  is  easy  to 
understand.  Therefore,  developing  software  systems  that 
interact  with  a  hierarchical  data  base  is  simplified. 
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The  disadvantages  of  a  hierarchical  DBMS  are  two.  One,  data 
items  do  not  always  logically  fit  into  a  hierarchical 
structure.  Two,  access  to  a  hierarchical  data  base  is 
limited  (i.e.,  from  the  top  of  the  structure  to  the  bottom 
of  the  structure).  Therefore,  the  design  of  the  data  base 
has  a  great  impact  on  the  amount  of  time  the  DBMS  requires 
to  access  a  particular  data  item.  Data  items  near  the  top 
of  a  hierarchical  structure  can  be  accessed  more  quickly 
than  those  at  the  bottom  of  the  structure. 

For  the  SDT,  the  order  of  desirability  of  the  logical 
structure  of  the  DBMS  at  the  conceptual  level  is  relational, 
network,  and  hierarchical.  The  remaining  DBMS  features  are 
examined  in  Section  3.6.1. 

3.5  RESTRUCTURING  OF  THE  SDT  INTO  A  RELATIONAL  FRAMEWORK 


Because  a  DBMS  with  a  relational  structure  was  preferred, 
the  SDT  components  were  restructured  into  a  relational-like 
framework.  The  components  are  described  in  "systems"  terms 
and  their  interrelationships  are  defined. 

3.5.1  Discussion  of  the  SDT  from  an  Entity-Attribute- 
Relationship  Perspective 

A  number  of  systems  analysts  (e.g.,  Teichroew,  Mascovic, 
Hershey,  and  Yamamoto,  1980?  and  Chen  1976)  have  pointed  out 
that  systems  can  be  described  in  terms  of  three  basic 
elements:  entities,  attributes,  and  relationships.  These 
three  elements  can  be  described  as  follows: 
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•  Entities  -  Correspond  roughly  to  nouns  in  English 
language.  They  are  those  objects  and  ideas  which  can 
be  used  to  describe  basic  system  elements. 

•  Attributes  -  Correspond  roughly  to  adjectives  in 
English  language.  Attributes  formalize  important 
properties  of  entities.  Each  attribute  has  associated 
with  it  a  set  of  values. 

•  Relationships  -  May  be  compared  with  English  verbs. 

More  properly,  they  correspond  to  the  mathematical 
definition  of  binary  relations;  statements  of 

associations  between  two  elements. 

This  simple  entity-attribute-relationship  framework  has  wide 
ranging  implications.  For  instance,  this  framework  has 
served  as  the  cornerstone  for  requirements  analysis  tools 

developed  in  the  ISDOS  project  at  the  University  of 
Michigan.  Thus,  it  provides  the  foundation  for  ail 
language-based  requirements  analysis.  More  important,  as 
was  noted  above,  it  is  directly  congruent  with  the  basic 

elements  of  a  relational  data  base  where  entities  correspond 
to  rows  in  a  relational  table,  attributes  correspond  to 
columns,  and  relations  correspond  to  the  table  entries. 

The  SDT  was  restructured  into  an  entity-attribute- 
relationship  framework  and  implicit  entity  and  attribute 
classes  and  SDT  relationships  were  identified.  Table  3-2 
lists  the  implicit  entity  and  attribute  classes  which  were 
developed  for  the  SDT.  Table  3-3  describes  the  different 
types  of  relationships  which  will  be  required  and  Table  3-4 
describes  how  these  different  types  of  relationships  can  be 
applied  to  the  different  classes  of  entities  and  attributes. 
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iMPLICIT  ENTITY  AND  ATTRIBUTE  CLASSES  FOR  DEVELOPING  WEAPON  SYSTEMS 


Entities 

Major  Attributes 

Functional  requirements 
data 

-  Functions 

Performance  goals,  threat  impacts,  environmental 
impacts,  mission  profile  impacts 

Design  Data 

-  Generic  equipment 
functions 

-  Design  alternatives 

-  Design  alternative 
component  inputs 

-  Design  alternative 
component  outputs 

Approval  status;  comparable  existing  equipments 

Comparable  existing  equipments,  degree  of  difference 
between  existing  equipment  ,  reliability 

Tasks/software  functions 

-  Human  tasks 
(individual) 

-  Human  task  inputs 

-  Human  task  outputs 

-  Software  functions 

Performance  data,  conditions,  standards,  initiating 
cues,  terminating  cues,  no.  of  people  performing, 
amount  of  supervision,  task  characteristics,  task 
assignments,  task  type,  task  elements 

Tools/tcst  equipment 

-  Tools 

-  Test  equipment 

Tool  type,  comparable  existing  tool 

Test  equipment  type,  comparable  existing  tool 

Personnel 

Function  (operator,  maintainer,  other),  MOS, 
skill  level,  paygrade,  duty  position  number 

Skill  and  knowledges  Skill  and  knowledge  characteristics 


Performance  measures  PM  type 


Learning  objectives 
Courses 

-  Course  modules 

LO  type,  training  setting,  training  method 

Course  seq.  no.;  course  no.;  title,  length,  hours; 
method,  student  /instructor  ratio 

Media 

Media  type;  training  setting 

ARTEP  (collecting  tasks) 

Related  manuals 

‘Attributes  specifying  relationships  between  entities  are  not  listed  (e.g.t  a  number 
or  code  relating  tasks  to  equipment)* 
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Table  3-3  TYPES  OF  RELATIONSHIPS  REQUIRED  BY  SDT 


(H)  Hierarchical  Relationships  -  A  is  a  member  of  B.  Relationship  indicates 
that  one  entity  is  a  member  of  larger  class  of  entities. 

(A)  Activity  Relationshps  *  A  occurs  before  (or  after)  B.  Relationship 
indicates  the  sequence  in  which  entities  (functions  or  tasks)  are 
performed. 

(10)  Input/Output  Relationships  -  Entity  A  is  an  input  (or  outpui)  of 
entity  B.  Relationship  indicates  inputs  and  outputs  associated  with 
entity. 

(As)  Associative  Relationships  -  A  is  associated  with  B.  Purely 
associative  relationships. 

(D)  Duplicative  Relationships  -  A  duplicates  B.  Different  versions  of 
a  general  entity  class  for  different  design  alternative. 
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Table  3-4  IMPLICIT  RELATIONSHIPS  IN  SDT 


Hierarchical  Relationships  (H) 

©  Within  each  entity  class,  each  class  can  be  subdivided  into  a  number  of  subclasses. 

•  Each  attribute  class  can  also  be  further  subdivided  into  a  number  of  subclasses. 

Activity  Relationships  (A) 

•  Activity  relationships  are  required  for  lower  level  functional  requirements 

•  Activity  relationships  are  required  for  tasks  (separate  relationships  for  operator 

and  maintenance  tasks) 

•  Activity  relationships  are  required  for  courses  (to  represent  course  sequence) 
Input/Output  Relationships  (I/O) 

•  Input/output  relationships  are  required  for  generic  equipments 

•  Input/output  relationships  are  required  for  design  alternatives 

•  Input/output  relationships  are  required  for  tasks 

Associative  Relationships  (As) 

•  All  attributes  must  be  associated  with  their  respective  entities. 

•  The  following  items  must  also  be  associated  with  one  another 

-  Generic  equipment  with  function 

-  Design  alternative  with  functions  and  generic  equipment 

-  Tasks  with  functions,  generic  equipment,  design  alternatives,  tools  and  test 
equipment,  personnel 

•  Software  functions  with  functions;  generic  equipment;  design  alternative;  tasks 

•  Tools  and  test  equipment  with  design  alternatives 

•  Skill  and  knowledges  with  tasks 

•  Learning  objectives  with  tasks,  skills  and  knowledges,  media,  courses,  and  course 
modules 

•  Performance  measures  with  tasks,  learning  objectives  and  skills  and  knowledges 

•  Courses  with  personnel,  design  alternatives  and  generic  equipment 

•  Course  modules  with  learning  objectives,  tasks,  skills  and  knowledges  and  media 

•  Media  with  tasks 

•  AKTEP  tasks  with  media,  tasks  and  functions 
Duplicative  Relationships  (D)  -  possible  with  any  entity 
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3.6  SELECTION  OF  A  DBMS  FOR  THE  SDT 


The  selection  procedure  consisted  of  the  following  three 
steps : 

1.  Determine  the  requirements  of  the  SDT  that  apply 
to  the  selection  of  a  DBMS  (Section  3.6.1), 

2.  Select  the  DBMSs  that  fulfill  these  requirements 
(Section  3.6.2), 

3.  Comapre  the  selected  DBMSs  to  determine  the 

DBMS  ( s )  most  applicable  to  the  SDT  (Section 

3.6.3) . 

Section  3.6.4  reviews  the  applicable  DBMSs.  Alternatives 
for  developing  and  operating  the  SDT  are  considered  in 
Section  3.6.5.  A  specific  recommendation  for  developing  and 
operating  the  tDT  is  given  in  Section  3.6.6. 

3.6.1  Determination  of  the  SDT  Requirements  that  Apply  to 
the  Selection  of  a  DBMS 

A  DBMS  with  a  relational  structure  at  the  conceptual  level 
was  desired  for  the  SDT.  However,  this  must  be  weighed 
against  other  DBMS  features  that  are  necessary  for 

development  of  the  SDT.  These  features  are  the  following: 

1.  Concurrent  batch  and  on-line  applications  -  A 

batch  operation  (i.e.,  reading  punched  computer 
cards)  can  be  performed  at  the  same  time  as  an  on- 


line  operation  (i.e.,  a  user  accessing  the  DBMS 
through  a  CRT  terminal). 

2.  Concurrent  on-line  access  for  multiple  users  - 
More  than  one  person  can  simultaneously  access  the 
DBMS  through  separate  CRT  terminals. 

3.  Security  restrictions  of  the  DBMS  -  The  DBMS  is 
inaccessible  to  unauthorized  users. 

4.  Aids  for  developing  user-friendly  interfaces  - 

Programming  tools  that  simplify  the  use  of  a  DBMS. 

5.  Query-facility  -  An  automated  aid  that  simplifies 
the  examination  and  retrieval  of  data  items  in  a 
data  base. 

6.  Data  dictionary  -  A  software  tool  that  contains 

descriptions  of  data  items  and  their  relation¬ 
ships,  but  not  the  data  items  themselves.  It  is 
used  to  control  the  development  and  operation  of  a 
data  base. 

7.  Report  generator  -  An  automated  utility  that 

simplifies  the  formatting  and  output  of  printed 
reports  on  the  data  in  a  data  base. 

8.  Variety  of  available  application  languages  -  The 

DBMS  must  interface  with  more  than  one  programming 
language  (i.e.,  COBOL,  PLI,  FORTRAN,  PASCAL, 
etc. ) . 
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9.  System  accounting  facility  -  An  automated  utility 
that  monitors  the  use  of  the  DBMS  resources  and 
its  supporting  facilities. 

10.  Journaling  or  logging  facility  -  An  automated 
utility  that  monitors  additions,  changes,  or 
deletions  of  data  in  the  data  base.  It  is  used  as 
an  "audit  trail"  for  data  base  operations. 

11.  Recovery  facilities  -  Automated  utilities  that 
restore  a  data  base  to  its  configuration  at  an 
earlier  point  in  time.  They  are  used  after  a 
computer  failure  to  return  the  contents  of  a  data 
base  to  their  previous  values. 

12.  Variable  length  segments  -  the  DBMS  will  accept 
data  items  whose  physical  storage  length  may 
vary.  This  feature  is  useful  for  data  items  with 
unknown  storage  requirements  or  for  data  items 
with  storage  requirements  that  could  change. 

These  12  DBMS  characteristics  apply  to  the  development  and 
operation  of  the  SDT .  Their  presence  in  a  DBMS  is  required. 

3.6.2  Selection  of  DBMSs  that  Fulfill  the  Requirements  of 
the  SDT. 

Fifty-one  (51)  commercial ly-available  DBMSs  were  surveyed 
through  a  study  of  DATA  PRO  reports  (70E-0lB-61a  and  D30- 
100-002)  and  other  literature. 

Table  3-5  summarizes  the  characteristics  of  the  51  DBMSs 
that  were  surveyed.  It  consists  of  six  items:  Vendor  of 
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TABLE  3*5 


CHARACTERISTICS  OF  COMMERCIALLY-AVAILABLE  DBMSs 


DBMS 

Vendor  of 
the  DBMS 

Supporting 

Hardware 

Approximate 

Usage 

Primary 

Data 

Organization 

Approx. 

Price 

Applicability  to 
SDT 

*ADABAS 

Software  AG  of  North 
America 

IBM:  360,370, 

303x,  4300 

Moderate 

Network 

$2500/ 
month 
$40-1 60 K 

Very  high 

ADM  INS/ II 

Admins,  Inc. 

DEC:  PDP-11, 
VAX-11 

Very  low 

Relational 

N/A 

Low 

AMBASE 

Amcour  Computer 
Company 

DEC:  PDP-11 

N/A** 

N/A 

$16.5  K 

Moderate 

BASIS 

Battalia,  Columbus 
Laboratories 

IBM;  COC;  Cyber; 
Univac;  DEC 

Very  low 

Relational-like 

$38K 

Moderate 

CREATE 

Complete  Computer 
Systems 

Data  General: 

NOVA  &  Eclipse 

Very  low 

N/A 

SISK 

Moderate 

*DATACOM/DB 

Applied  Data  Research, 
Inc. 

IBM:  380,370 

Low 

Relational 

S47-57K 

Very  high 

DATA  OEMON 

Gemini  Information 
Systems,  Inc. 

Perkin-Elmer; 

IBM:  Series/1 

Very  low 

N/A 

$1000/ 

month 

S17.5K 

Low 

DBM-1 

Condor  Computer  Corp. 

Cromenoo: 

System/3 

Very  low 

N/A 

$10K 

Low 

DBMS 

Prime  Computer,  Inc. 

Prime:  400  &  500 

N/A 

SI-4 - i- 

PMlWOrK 

$20  K 

Low 

DBMS  2 

EGS  Systems.  Inc. 

Modular  Computer: 
MODCOMP 

Very  low 

N/A 

N/A 

Very  low 

DBMS-10 

DEC 

DEC:  System-10 

Low 

Network 

S30K 

High 

DBMS-11 

DEC 

DEC:  POP-11 

N/A 

Network 

S1S.5K 

Low 

DBMS-20 

DEC 

DEC:  System-20 

Very  low 

Network 

$30K 

High 

DBMS-300 

Compudeta  Systems,  Inc. 

DEC:  300  Series 

Very  low 

N/A 

$100/mo 

S6K 

Very  low 

DBMS-900 

Texas  Instruments.  Inc. 

Tl:  DS990, 

Models  •  1  9 

N/A 

N/A 

S2K 

Very  low 

DL/I  DOS/VS 

IBM 

IBM:  370, 

303x,  4300 

High 

Hiererohicel 

$434/ mo 

High 

DMS  II 

Burroughs  Corp. 

Burroughs:  B 

700  or  900 

Low 

Network 

$23. 25k 

High 

DMS  90 

BfpPnr  ufiific 

llnivec:  Series 

90  or  90 

V'ry  low 

- 1. 

N/A 

Moderate 

DMS- 170 

Control  Data  Corp. 

COC.SOOO;  Cyber 

70.  170,  700 

Very  low 

|IM  I  I  ,4, 

fHleV9ni 

S730/mo 

High 

DMS-1100 

Sperry  Univec 

Unite©  1100 

Series 

Mode  *  ate 

sr — - a_ 

N/A 

t.«h 

DMS/1700 

Dedieetad  t  yets  no.  Inc 

Burro  mbs:  81700 

N/A 

N/A 

Low 

DNA-Oeta 

Exact  lyetama  1 
Programming  Carp. 

DO:  Nova  or 

Calipee 

Very  low 

N/A 

N/A 

Very  low 

•OBMS  mm**  for  further  study. 
**Net  MiMli, 
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Table  3-5  (continued) 


DBMS 

Vendor  of 
the  DBMS 

Supporting 

Hardware 

Approximate 

Usage 

Primary 

Data 

Organization 

Approx. 

Price 

Applicability  to 
SDT 

OPL 

National  Information 
Systems,  Inc. 

OEC:  System 

10  or  20 

Low 

Hierarchical 

S8«0/mo 

S38-47K 

High 

DRS/XBS 

A.R.A.P. 

IBM,  DEC.  Univac, 
CDC 

Low 

Network 

S22-60K 

High 

EASE  DBMS 

Bloodstock  Computer 
Services.  Inc. 

DEC.  PDP-11 

Very  low 

N/A 

S6.5K 

Low 

GIS/2 

IBM 

IBM:  360  or 

370 

N/A 

Hierarchical 

1620-970/ 

mo 

Moderate 

IBDB 

T ws arret  Corp. 

IBM:  SerieVI 

Vary  low 

N/A 

$4.1  K 

Low 

•IDS— I/ll 
(OM-IV) 

Honeywell  Info. 

Systems,  Inc. 

Honeywell:  Series 
6000  &  60  Level  66 

High 

Network 

S400-S2K/ 

mo 

Very  high 

•IDMS 

Cullinene  Corp. 

IBM:  360,370, 

303x,  ft  4300 

Moderate 

Network 

$50K/yr 

Very  high 

IDOL 

Corporation 

Wang:  2200; 

IBM:  Series  1 

Low 

N/A 

$364/ mo 
99500 

Moderate 

IMS 

IBM 

IBM:  360.370. 

303a.  4300 

Vary  high 

Hierarchical 

$1046/ 

mo 

UU, 

Infoflex  DBM 

Interactive  info. 

Systems.  Inc. 

DEC:  Dataaystem 

600  Series 

Vary  low 

N/A 

S12K 

Low 

INFOMEDIA 

ESaaJ  y ealtufi  Ifirt]  ■ 

mm  i  ocnnoiogy 

Laboratories 

IBM:  360  or  370 

N/A 

N/A 

92000/ 

mo 

S140K 

Low 

INFOTRIEVE 

Educational  Data 

tiMeoMa 

•yfwftrl 

EDS:  Point  4. 

DO:  Nova 

Vary  low 

N/A 

92000 

**  -» - - 

MMV9II 

INGRES 

INGRES.  Inc. 

DEC:  FOP-11 

Lew 

Relational 

N/A 

Low 

IQ/NET 

Iwlaulote  f1,  ^  |«|» 

unuuiiB  cysifiiMi  me, 

IBM:  4300 

N/A 

y^.  -  -A 

940K 

Moderate 

INQUIRE 

infodata  Systems,  Inc. 

IBM:  360.  370 

Low 

-  — *■ 

970-1 SOX 

High 

MADMAN 

Q.E.  Company 

DEC:  POP-11 

N/A 

Relational  Hka 

920X 

Low 

MIOMS 

ei-^i - —•  T  ■  rA  m  1  n  ■  1 

inly,  fvnv 

IBM:  360 

N/A 

N/A 

9480 

Medwm. 

MINOS 

Mbmeaota  Detasydemx 

Inc. 

•Tl:  4000. 

9000,  or  6000 

Very  lew 

N/A 

SUK 

Lew 

•MODEL  20* 

Computer  Corp.  of 
America 

ISM;  310.  370. 

303a.  or  4300 

Vary  lew 

a* -  -  A- 

•MwDFR 

9fO-1ftOR 

Very  Mgh 

OASIS 

University  of  Windsor 

ISM:  ISO.  370. 
or  303a 

Very  lew 

N/A 

930 X/ye 

Lew 

ORACLE 

DEC:  POP11  or 

VAX 

N/A 

ReNUenel 

MnNme. 

OS  200  OS 

(Moooyvvolt 

Honeywell:  300 
or  3000 

Very  lew 

N/A 

tree  with 
Hardware 

Vary  low 

PLUS/* 

Celery  Analyst*.  Ina. 

NCR:  101  * 

N/A 

N/A 

S10K 

Lew 

QCRT 

i 

1 

21 

MMc  300  er  370c 

Very  lew 

N/A 

926X 
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Tpbto  3-5  (continued) 


DBMS 

Vtndor  of 
tfw  DBMS 

Supporting 

Hardwire 

Approximate 

Usage 

Primary 

Data 

Organitation 

Approx. 

Price 

Applicability  to 
SDT 

*  RAMIS  II 

Mcthamatica 

Products  Group 

IBM:  2B0  or  370 

Hid! 

set - a. 

S22-43K 

Vary  hi* 

•KIO 

International  Octi  Sect 
Sydwn,  Inc. 

IBM;  COC;  HP; 
end  OEC 

Very  low 

- a- 

WWwOfw 

SB.S-25K 

Very  high 

lupmitup 

The  Auto  meted 

Quill,  Inc. 

DO:  Nova  or 

Edipaa 

Very  low 

N/A 

S4.BK 

Low 

SYSTEM  1022 

Software  House 

OEC:  System 

10  or  20 

Low 

Hetational 

S24K 

SYSTEM 

2000/S0 

■mW  MfflwBS 

Corporation 

IBM:  COC:  and 
UnHoc 

Moderate 

S46K 

Hi* 

TOTAL 

Oneom  Systems.  Inc. 

IBM  ft  moat 

Very  high 

S1MK 

the  DBMS,  Supporting  Hardware,  Approximate  Usage,  Primary 
Data  Organization,  Approximate  Price,  and  Applicability  to 
SDT . 

Vendor  of  the  DBMS  refers  to  the  company  that  distributes 
the  DBMS.  It  was  included  to  provide  additional 

information . 

Supporting  Hardware  refers  to  the  computer  hardware 
configuration  on  which  the  DBMS  will  operate.  In  some 
instances,  only  the  names  of  the  hardware  manufacturers  were 
included.  In  these  instances,  the  DBMS  will  operate  on  more 
than  one  configuration  (or  model)  of  the  listed  comouter 
hardware. 

Approximate  Usage  is  an  estimate  of  the  number  of 
installations  of  the  DBMS.  It  is  based  on  the  following 
scale: 


•  Very  high  -  greater  than  1,500  installations, 

•  High  -  1000  to  1,499  installations, 

•  Moderate  -  500  to  999  installations, 

•  Low  -  100  to  499  installations,  and 

•  Very  low  -  less  than  100  installations. 

It  infers  a  rough  measure  of  the  popularity  of  a  DBMS  within 
the  computer-user  community.  However,  this  inference  does 
not  imply  that  a  greatly  used  system  is  better  than  one  of 
less  usage. 

Primary  Data  Organization  is  the  logical  structure  of  the 
data  base  at  the  conceptual  level.  The  structure  can  be 
relational,  network,  hierarchal,  or  a  combination  of  these 
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three.  However,  only  the  most  commonly  referenced  structure 
is  listed. 

Price  refers  to  the  basic  system  purchase  price  that  was 
quoted  to  DATA  PRO  in  late  1980.  The  purchase  price 
generally  includes  an  unspecified  monthly  maintenance 
charge.  Monthly  or  yearly  lease/rental  plans  are 

occassionally  included. 

The  column  entitled  Applicability  to  SDT  is  a  composite  of 
the  12  SDT  requirements  identified  in  Section  3.6.1.  Each 
DBMS  was  examined  to  determine  how  many  of  these  12 
requirements  it  fulfilled.  The  scale  used  follows: 

•  Very  high  -  All  12  requirements  fulfilled, 

•  High  -  9  to  11  requirements  fulfilled, 

•  Moderate  -  5  to  8  requirements  fulfilled, 

•  Low  -  3  to  4  requirements  fulfilled,  and 

•  Very  low  -  2  or  fewer  requirements  fulfilled. 

This  column  is  the  deciding  factor  for  selecting  DBMS 
alternatives  for  the  SDT.  Only  those  DBMSs  that  ranked  very 
high  (fulfilled  all  12  SDT  requirements)  were  selected  for 
further  analysis.  These  DBMSs  are  marked  with  an  asterisk 
(*). 

3.6.3  -  Comparison  of  the  Selected  DBMS  Alternatives 

The  seven  DBMSs  that  were  selected  for  further  analysis  were 
ADABAS,  DATACOM/DB,  IDS-l/lI  (DM-IV),  IDMS,  MODEL  204,  RAMIS 
II,  and  SEED.  Each  of  these  DBMSs  fulfilled  the  12  SDT 
requirements. 
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Table  3-6  displays  the  factors  that  were  selected  to 
evaluate  the  seven  DBMS  alternatives.  These  factors,  and 
their  rating  systems,  follow: 

I  Primary  Data  Organization  -  The  major  data  base 

structure  at  the  conceptual  level  of  system 

architecture.  The  three  main  types,  ranked  in  order  of 
their  applicability  to  the  SDT,  are  relational  (3), 
network  (2),  and  hierarchical  (1). 

II  Usage  -  The  number  of  installations  of  the  DBMS.  The 
scale  for  usage  is:  over  1,500  installations  (3),  500 
to  1,500  installations  (2),  and  under  500  installations 
(1). 

III  Selected  Features  -  Of  the  12  SDT  requirements  examined 
earlier,  six  were  selected  for  further  study.  These 
six  requirements  were  fitted  to  the  following  scale: 
enhanced  (3),  sufficient  (2),  and  insufficient  (1). 
The  scale  signifies  the  extent  to  which  the  SDT 
requirement  is  fulfilled.  For  example,  a  rating  of  1 
states  that  the  DBMS  does  not  sufficiently  fulfill  a 
SDT  requirement. 

1.  System  security  refers  to  the  extent  of  data 

protection  in  the  DBMS.  The  characteristic  of  an 
insufficient  security  facility  is  DBMS  validation 
of  the  user's  password.  A  sufficient  facility  has 
password  validation  and  protects  data  from 
unauthorized  modification.  An  enhanced  facility 
combines  password  validation  and  modification 
protection  with  protection  against  unauthorized 
data  viewing  and/or  data  encryption. 
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TABLE  3-6 


EVALUATION  OF  SELECTED  DBMS  ALTERNATIVES  FOR  THE  SDT 


AO  ABAS  DATACOM/DB  IDS  I/ll  *  IDMS  *  MOO  El  204  RAMIS  II  SEED* 

(DM-IVI 


I.  Primary  Data  Organization 
Ratational-3 
Seal#  <  Nat  work -2 

Hierarchical- 1 


II.  Usage 


>1500  Users- 3 


Scale  <  500-1500  Users-2 
[<500  Users- 1 

III.  Selected  Features 

1.  System  security 

2.  User-friendly  aids 

3.  System  accounting  facilities 

4.  Transportability 

5.  Inquiry/retrieval 

6.  Report  generator 

Enhanoed— 3 
Scale  Sufficient— 2 

Insufficient- 1 


IV.  Total 


*DBMSs  with  greatest  total  score. 
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2.  User-friendly  aids  are  software  tools  that 

simplify  user  interaction  with  the  DBMS.  An 

insufficient  aid  simplifies  the  development  of 
application  programs.  A  sufficient  aid  has  a 
"HELP"  facility  to  provide  the  user  with  on-line 
documentation  about  system  functions.  An  enhanced 
facility  provides  an  on-line  tutorial  that  is 
oriented  to  the  uninitiated  user. 

3.  System  accoutning  facilities  automatically  track 

the  use  of  system  resources.  An  insufficient 
facility  would  only  track  statistics  of  DBMS 
utilization.  A  sufficient  facility  would  log 

these  statistics  and  simplify  the  development  of 
an  equitable  algorithm  for  billing  system  users. 
An  enhanced  facility  would  produce  user  billing 
reports  based  on  logged  statistics  and  the  billing 
algorithm. 

4.  Transportability  is  the  ability  to  use  the  DBMS  on 

different  computers.  An  insufficiently 

transportable  DBMS  can  only  be  used  on  a  single 
model  of  a  computer  (i.e.,  IBM  370).  A 

sufficiently  transportable  DBMS  can  be  used  on 
more  than  one  model  of  a  line  of  computers  of  a 
single  manufacturer  (i.e.,  IBM  360,  370,  and 

3033).  Enhanced  transportability  is  a  DBMS  that 
can  be  used  on  a  variety  of  computers  of  different 
manufacturers  (i.e.,  IBM,  UNIVAC,  and  Honeywell). 

5.  Inquiry/retrieval  facility  is  the  utility  that 
simplifies  user  access  to  data  in  a  data  base.  An 
insufficient  facility  is  used  through  application 
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programming  languages  only.  A  sufficient  facility 
is  available  to  the  on-line  user.  An  enhanced 
facility  has  an  on-line  language  with  simple, 
English-like  text. 

6.  Report  generators  simplify  the  formatting  and 
output  of  the  data  base  reports.  An  insufficient 
generator  is  used  through  application  programming 
languages  only.  A  sufficient  generator  is 
available  to  the  on-line  user.  An  enhanced 

generator  has  an  on-line  language  with  simple, 
English-like  text. 

The  six  SDT  requirements  that  were  not  selected  for  further 
analysis  were  generally  equivalent  in  each  of  the  seven 
alternative  DBMSs. 

The  DBMSs  with  the  greatest  total  scores  are  most  suitable 
for  the  develoment  and  operation  of  the  SDT.  These  DBMSs, 
marked  with  asterisks  {*),  are  IDMS,  IDS-l/lI  (DM-IV),  and 
SEED. 


3.6,4  Review  of  the  Applicable  DBMSs 

IDMS  is  a  Cull  inane  Corporation  DBMS  that  conforms  with  the 
CODASYL  PLC  DBTG  specifications.  It  operates  on  several  IBM 
mainframe  computers.  Some  features  of  IDMS  are  the 
following: 


•  Data  dictionary, 

•  Optional  query  facility, 

•  Optional  report  generator, 

•  Network  data  base  structure, 
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•  Requires  75 , 000  bytes  of  on-line  storage  space, 
and 

•  One  year  license  fee  of  $50,000. 

The  strengths  of  IDMS  are  its  CODASYL  orientation  and  the 
good  reputation  of  its  vendor — Cullinane  Corporation.  It 
has  over  700  installations. 

IDS  I/II  (DM-IV)  are  Honeywell  software  products  with  over 
1,000  installations  on  Honeywell  mainframe  computers.  IDS  I 
(Integrated  Data  Store  I)  was  introduced  in  1974  and  was 
considered  a  "defacto"  CODASYL  PLC  DBTG  system.  IDS  II  was 
introduced  in  1975  and  conforms  completely  to  the  CODASYL 
PLC  DBTG  standards.  DM-IV  (Data  Manager-IV)  is  a  File 
Management  System  that  integrates  IDS  II  (the  DBMS)  with 
supporting  software  systems  to  provide  complete  data 
management  facilities.  Some  of  the  features  of  DM-IV/IDS  II 
are  the  following: 

•  Data  Dictionary, 

•  Query  facility, 

•  Report  generator, 

•  Network  data  base  structure, 

•  Multiple  application  languages, 

•  Requires  12,000  words  of  on-line  storage  space, 
and 

•  Priced  at  $2 , 300 /month . 

The  strengths  of  DM-IV/IDS  II  are  its  CODASYL  orientation, 
popularity,  and  the  support  of  its  vendor  -  Honeywell,  Inc. 

SEED  is  a  DBMS  product  of  International  Data  Base  Systems, 
Inc.  It  is  primarily  written  in  FORTRAN  and  has  been 
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installed  on  a  variety  of  computers.  However,  it  has 
relatively  few  installations.  Some  features  of  SEED 

follow: 

•  Data  dictionary, 

•  Optional  Query  facility, 

•  Optional  Report  generator, 

•  Network  data  base  structure, 

•  Requires  20,000  to  50,000  bytes  of  on-line  storage 
space,  and 

•  Priced  from  $9,000  to  $15,000. 

SEED’s  strengths  are  its  high  degree  of  transportability  and 
its  low  price. 

3.6.5  Alternatives  for  Developing  and  Operating  the  SDT 

Three  alternatives  for  developing  and  operating  the  SDT  have 
been  identified.  They  are  the  following: 

1.  DRC  personnel  develop  the  SDT  on  non-DRC  computer 
equipment.  This  equipment  is  selected  for  its 
compatibility  to  existing  Army  computer 
hardware.  The  SDT  is  developed  with  a  DBMS  that 
is  highly  transportable  -  SEED  -  and  the  necessary 
programming  aids.  The  SDT  resides  in  the  selected 
computer  hardware  and  is  accessed  through  remote 
and  local  terminals.  The  users  are  responsible 
for  operating  the  SDT.  DRC  maintains  the  SDT, 
probably  through  a  remote  terminal  interface. 

2.  DRC  develops,  implements,  maintains,  and  operates 
the  SDT  on  DRC’s  Honeywell  DPS-8/52  computer.  The 
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SDT  is  developed  using  DM-IV/IDS  II,  Middleware, 
and  other  programming  aids  available  at  DRC.  The 
users  access  the  SDT  through  remote  terminals 
interfaced  to  DRC's  computer  facility. 

3.  DRC  develops  and  implements  the  SDT  on  an  Apple  II 
Plus  microcomputer  with  an  interface  to  a  DBMS 
that  will  reside  in  DRC's  Honeywell  computers. 
The  users  access  the  SDT  DBMS  through  remote  Apple 
II  Plus  Microcomputers  with  resident  SDT  software 
(i.e.,  the  computer  programs  that  will  reside  in 
the  Apple  II  Plus  microcomputers  and  perform  the 
SDT  functions).  DRC  operates  and  maintains  the 
SDT  DBMS  and  maintains  the  SDT  software. 

3.6.6  Specific  Recommendation  for  Developing  the  SDT 

At  this  time,  DRC  recommends  the  third  alternative  - 
developing  and  operating  the  SDT  using  a  DRC  DBMS  with  the 
user  interfaces  through  Apple  II  Plus  microcomputers. 

The  first  alternative  -  developing  the  SDT  on  a  non-DRC 
computer  and  DBMS  •  is  rejected  because  of  the  cost  of 
familiarizing  the  DRC  staff  with  this  configuration.  The 
SDT  could  not  be  developed  given  the  current  funding 
constraints.  In  addition,  the  effectiveness  of  remote 
terminal  maintenance  of  the  SDT  is  questionable.  Travel 
time  for  the  SDT  maintenance  crew  would  have  to  be  included 
in  a  cost  estimate  of  this  alternative. 

The  advantages  of  alternative  two  -  developing  the  SDT  using 
DRC *8  Honeywell  DPS-8/52  computer  and  the  DM-IV/IDS  II  -  are 
the  following! 
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1.  DRC  has  the  necessary  computer  hardware  and 

supporting  software  to  develop  and  operate  the 

SDT. 

2.  DRC  personnel  are  familiar  with  this  computer 

configuration. 

3.  DRC's  DM- IV/ IDS  II  is  one  of  the  three  DBMSs 

recommended  for  the  SDT. 

4.  DRC  computer  facilities  are  available  seven  days  a 
week,  24  hours  a  day. 

Alternative  two  is  recommended  if  alternative  three  is 
technically  and/or  economically  infeasible. 

Alternative  number  three  -  developing  the  SDT  on  an  Apple 
computer  with  an  interface  to  a  DRC  DBMS-requires  further 
study  to  determine  its  technical  and  economic  feasibility. 
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SECTION  4  -  SDT  DESCRIPTION 


This  section  provides  a  detailed  description  of  the  SDT. 
The  description  builds  upon  all  of  the  research  and 
development  conducted  during  the  first  year  of  the  study, 
including  the  review  of  existing  DoD  and  Army  policies  and 
procedures  (Appendix  A),  the  review  of  psychological 
literature  relating  to  the  design  process  (Appendix  B),  the 
review  of  literature  relating  to  human-computer  interactions 
(Appendix  C),  the  SDT  information  specification  (Section  2), 
and  the  review  of  automated  system  description  tools 
(Section  3).  The  description  outlined  in  this  chapter  is 
expected  to  serve  as  an  example  of  the  major  SDT  development 
efforts  which  will  occur  during  the  second  year. 

The  chapter  is  divided  into  seven  sections.  The  first 
section  will  provide  an  overview  of  the  optimal  SDT 
characteristics.  The  second  section  will  describe  the 
likely  users  of  the  SDT.  The  third  section  will  provide  a 
description  of  the  physical  characteristics  of  the  SDT.  The 
fourch  section  will  provide  an  overview  of  the  basic  SDT 
process.  The  fifth  section  will  describe  its  different 
modes  of  operation.  The  sixth  section  will  provide  a  more 
detailed  description  of  the  operational  uses  of  the  SDT  by 
listing  examples  of  the  types  of  interactions  that  can  be 
expected  under  each  mode  of  operation.  The  final  section 
will  describe  the  features  of  an  initial  version  of  the 
SDT.  During  the  present  three  year  ETES  study,  the  goal 
will  be  to  develop  the  initial  version  and  then  to  augment 
it  with  as  many  features  of  the  optimal  version  as  is 
possible  until  the  funds  allotted  in  the  present  study  have 
been  expended.  This  strategy  is  necessary  to  insure  that  an 
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operational  SDT  product  will  be  available  at  the  end  of  the 
study.  Actually,  even  the  initial  version  of  the  SDT  will 
be  a  rather  sophisticated  and  powerful  tool. 

4.1  OVERVIEW  OF  SDT  FEATURES  AND  RELATIONSHIP  TO  OTHER 
SECTIONS 


The  SDT  will  be  an  automated  tool  for  describing  actual  and 
projected  system  elements,  including  functional 
requirements,  design  concepts,  task  skills,  training  program 
elements  and  their  associated  resources;  for  storing  the 
above  information?  for  changing  and  updating  this 
information?  and  for  transmitting  the  information  among  all 
of  the  participants  in  the  acquisition  process. 

A  detailed  description  of  the  information  elements  which 
will  be  described  by  the  SDT  is  in  Section  2.  Description 
of  the  use  of  the  SDT  within  the  context  of  early  training 
estimation  and  existing  Army  policies  and  procedures  is  in 
Appendix  A  and  Section  2.4. 

As  a  result  of  the  review  of  automated  tools  described  in 
Section  3,  a  data  base  management  system  was  determined  to 
be  the  best  vehicle  for  the  SDT.  Finally,  the  SDT  will  be 
specifically  designed  to  meet  the  human-computer  interaction 
requirements  for  uninitiated  users  identified  in  Appendix  C, 

4.2  USERS  OF  SDT 


The  SDT  will  be  accessed  by  three  different  groups:  (1) 
Primary  Users  -  Primary  Users  are  the  people  who  will 
actually  use  the  SDT  on  a  "day-to-day"  basis  to  describe  and 
update  system  concepts  and  to  obtain  information  on  current 


4-2 


system  characteristics  (Table  4-1  lists  the  organizations 
that  are  likely  to  be  the  primary  users  of  the  SDT  for  an 
emerging  weapon  system),  (2)  Data  Base  Directors  (DBDs )  - 
the  DBDs  validate  the  design  and  utilization  of  the  SDT  data 
base,  and  (3)  SDT  Management  Group  -  the  SDT  Management 

Group  maintains  and  operates  the  SDT. 

4.2.1  Primary  Users 

Each  primary  user  will  be  connected  to  the  SDT  by  at  least 
one  remote  terminal.  Some  primary  user  organizations  (e.g., 
training  developments  and  the  DARCOM  PM)  are  likely  to  have 
more  than  one  terminal  since  they  will  have  a  number  of 

individuals  with  a  need  for  SDT  data  base  information.  It 
is  expected  that  all  primary  users  will  interface  with  the 
SDT  in  an  interactive  mode.  To  input  data  in  a  batch  mode, 
they  must  transmit  this  data  to  either  the  Data  Base 
Directors  or  the  SDT  Management  Group  who  will  then  input 
the  data  into  the  system.  It  is  expected  that  the  primary 
u^ers  of  the  SDT  will  have  little,  if  any,  computer 

skills.  Consequently,  all  of  their  interactions  with  the 
SDT  will  be  through  a  highly  transparent  user  interface  that 
will  utilize  menu-selection,  form-filling,  and  question-and- 
answer  computer  dialogue  techniques  to  elicit  innut  data  and 
commands  (see  Appendix  C  for  a  discussion  of  these 

techniques).  This  type  of  transparent  interface  will  mean 
that  the  users  will  only  be  required  to  learn  the  commands 
associated  with  calling  up  the  SDT  system.  From  that  point 
on,  they  will  be  led  through  the  utilization  of  the  SDT  and 
will  not  have  to  generate  any  more  commands  on  their  own, 
(They  should,  of  course,  have  read  the  SDT  users  manual  to 
find  how  the  SDT  can,  and  should,  be  used.) 
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Tabic  4-1  PRIMARY  USERS  OF  SDT 


TRADOC  System  Manager  (TSM)  for  System 
Training  Developments  (within  Related  School)1 
Combat  Developments  (within  Related  Mission  Area) 

DARCOM  Program  Management  Staff  for  System1 
TRADOC  Systems  Analysis  Activity  (TRANSANA) 

DARCOM  Materiel  Readiness  Support  Activity  (MRSA)^ 

Individual  Contractors 
Others 

Hndicatcs  organization  likely  to  have  more  than  one  terminal  interfacing  with 
SDT. 

2The  MRSA  connection  with  the  SDT  will  be  designed  to  provide  .in  SDT  interface 
with  the  automated  LSAR. 
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4.2.2  Data  Base  Directors  ( DBDs ) 


The  DBDs  will  have  the  same  capabilities  as  the  primary 
users  for  entering,  storing,  and  accessing  SDT  informa¬ 
tion.  The  Data  Base  Directors  will  have  two  additional 
responsibilities : 

a.  The  DBDs  will  be  responsible  for  overseeing  the 
general  development  of  a  system-specific  SDT  data 
base.  In  this  role,  they  will  direct  the  SDT 
Management  Group  to  set  up  and  maintain  a  data 
base  for  the  system;  direct  others  to  input, 
update,  and  utilize  SDT  data;  and  determine  what 
data  elements  can  be  changed,  who  can  change  them, 
and  when  they  can  be  changed. 

b.  The  DBDs  will  have  the  capability,  together  with 
the  SDT  Management  Group,  for  batch  input  and  for 
producing  block  diagrams  to  represent  various 
system  relationships. 

It  is  expected  that  the  DBDs  will  also  be  uninitiated  users 
with  little,  if  any,  computer  experience.  Consequently, 
they  will  interact  with  the  SDT  via  the  same  transparent 
user  interface  that  will  be  used  with  the  primary  users 
(i.e.,  menu  selection,  form-filling,  and  question-and-answer 
dialogues).  Management  directions  for  the  SDT  will  be 
transmitted  via  normal  communications  media  (e.g.,  mail, 
phone)  and  not  through  the  automated  SDT. 

It  is  likely  that  one  of  the  user  organizations  listed  in 
Table  4-1  will  also  fill  the  Data  Base  Directors  role  (the 
most  likely  candidates  being  Training  Developments,  the  TSM, 
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or  the  DARCOM  PM)  .  Exact  specification  of  an  organization 
to  fulfill  this  role  will  be  made  during  the  ETES 
implementation  phase.  It  may  be  necessary  to  create  a 
multidisciplinary  group  from  combat  developments,  training 
developments,  and  the  TSM  group  at  a  specific  school  to 
assist  the  DBDs  in  performing  their  functions  rather  than 
relying  on  a  single  organization. 

4.2.3  SDT  Management  Group 

The  SDT  Management  Group  will  be  responsible  for  overseeing 
the  application  of  the  SDT  on  an  Army-wide  basis.  In  this 
capacity,  they  will: 

Maintain  and  update  the  SDT-DBMS  including 
computer  programs  relating  to  data  input  and 
output,  data  storage  and  retrieval,  and  the  DBMS 
external,  conceptual,  and  internal  models. 

Operate  the  central  processor  to  handle  SDT 
applications  and  direct  its  use  among  the  various 
SDT  users. 

Direct  and  maintain  the  physical  storage  of  the 
SDT-DBMS  system  programs,  the  system-specific  data 
bases,  and  the  archival  files. 

Provide  a  batch  input/output  and  graphics  output 
capabilities  (in  addition  to  the  standard  SDT 
input/ output  capabi 1 ities ) . 

Assist  users  and  DBDs  in  utilizing  the  SDT. 
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Provide  formal  training  to  SDT  users. 


Plan,  develop,  and  implement  short-term  and  long¬ 
term  SDT  improvements. 

Provide  data  to  other  Army  organizations  for 
related  applications  (e.g.,  total  force 
requirements  analysis). 

Promote  the  use  of  the  SDT  among  Army 

organizations . 

In  contrast  to  the  other  two  SDT  user  groups,  the  SDT 
Management  Group  is  expected  to  have  individuals  with 
sophisticated  computer  backgrounds  —  sophisticated  enough 
to  develop  and  maintain  programs  for  all  of  the  SDT 
functions.  In  addition  to  fluency  in  standard  computer 
languages,  the  SDT  Management  Group  will  require  individuals 
that  understand  the  SDT-DBMS  system. 

4.3  PHYSICAL  DESCRIPTION  OF  SDT 

Figure  4-1  provides  a  general  description  of  the  SDT 
physical  characteristics.  The  design  outlined  in  Figure  4-1 
should  minimize  requirements  for  the  purchase  of  new 
equipment  by  participating  Army  organizations.  More  details 
on  the  hardware  associated  with  the  three  different  user 
groups  is  presented  in  the  sections  which  follow. 

4.3.1  Physical  Description  of  Primary  User  Hardware 

The  primary  users  of  the  SDT  will  each  require  a  terminal 
with  a  keyboard,  a  CRT  with  textual  capabilities  (as  a 
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minimum),  and  a  printer.  This  set  of  equipment  will  allow 
the  user  to  input  data  interactively;  to  access,  update,  and 
modify  data;  and  to  receive  outputs  of  SDT  information  in 
tabular  listings,  which  will  be  the  standard  SDT  output 
format.  However,  the  primary  users  will  not  be  able  to 
directly  input  batch  data  or  to  produce  output  in  block 
diagram  form^ .  However,  they  can  have  these  functions 
performed  indirectly  through  the  DBDs  or  the  SDT  Management 
Group.  There  are  two  major  reasons  for  not  providing  the 
primary  users  with  these  additional  capabilities.  First, 
the  SDT  is  geared  to  be  utilized  with  existing  equipment  and 
it  is  likely  that  a  number  of  primary  users  will  not  have 
access  to  the  equipment  (plotters,  CRT  terminal,  card 
reader,  and  tape  reader)  required  to  provide  batch  input  and 
graphical  output.  To  provide  these  users  with  such 
equipment  would  be  very  expensive  and  this  expense  would  be 
likely  to  diminish  SDT  utilization.  Second,  all  of  the 
information  contained  in  the  block  diagrams  could  be 
represented  in  tabular  format.  Admittedly,  this  data  may  be 
slightly  more  difficult  to  understand  in  this  format. 
However,  the  analyst  need  only  utilize  this  data  until  a 
diagram  is  obtained  from  the  DBDs  or  the  SDT  Management 
Group. 

It  should  be  noted  that  some  primary  users  (e.g.,  training 
developments,  program  managers)  are  likely  to  have  more  than 
one  of  the  terminal  set-ups  described  in  Figure  4-1. 


An  alternative  conceptualization  of  the  primary  user 
equipment  set-up  which  is  being  considered  is  to  have  each 
primary  user  have  his  own  intelligent  terminal  with 
accompanying  graphics  capabilities. 
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4.3.2  DBDs  Physical  Equipment  Description 


The  DBDs  will  have  the  same  physical  equipment  as  the 
primary  user  (remote  terminal,  CRT  display,  and  printer) 
plus  additional  equipment  to  provide  a  batch  input 
capability  (card  readers  and  tape  readers)  and  a  graphics 
output  display  capability  for  block  diagrams  (plotter) .  It 
should  be  noted  that  the  DBDs  is  likely  to  be  one  of  the 
primary  users  (most  likely  the  TSM,  PM,  or  training 
developments).  Also,  primary  users  who  have  a  great  demand 
for  a  batch  input  capability  or  a  graphics  output  capability 
could  add  the  appropriate  hardware  without  any  disruption  of 
the  overall  system. 

4.3.3  SDT  Management  Group  Physical  Equipment  Description 

The  SDT  will  have  all  of  the  hardware  capabilities  of  the 
DBD  (terminal,  CRT  display,  printer,  and  reader,  tape 
reader,  and  plotter)  plus  the  central  processor,  and 
physical  storage  capabilities  for  the  SDT  DBMS  programs, 
system-specific  data  bases,  archival  data,  and  data 
dictionaries.  Thus,  the  SDT  Management  Group  will  require  a 
fairly  complete  data  processing  capability. 

4.4  OVERVIEW  OF  SDT  PROCESSES 


An  overview  of  the  general  SDT  processes  is  presented  in 
Figure  4-2.  The  SDT  will  have  the  capability  of  inputting 
three  different  types  of  data:  batch  input  of  SDT  data 
sheets,  batch  input  of  related  acquisition  data,  and 
interactive  input  of  SDT  data  sheets.  The  SDT  DBMS  external 
model  will  provide  the  mechanism  for  reading  this  input  data 
and  translating  it  into  a  format  suitable  for  the  conceptual 
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model.  Directions  for  interactive  input  of  data  will  be 
provided  by  the  SDT  executive  director  programs.  The  SDT 
input  data  will  be  translated  into  a  form  which  matches  the 
conceptual  model  of  the  DBMS.  Once  it  has  been  translated, 
the  data  will  be  evaluated  for  consistency  against  data 
already  in  the  data  base  and,  if  consistent,  the  data  will 
be  entered  into  the  system-specific  data  base.  However, 
this  will  be  done  only  after  the  SDT  executive  director  has 
determined  that  the  user  has  been  cleared  to  enter  that  type 
of  data  into  the  data  base. 

Once  in  the  data  base,  the  data  is  continuously  updated, 
modified,  and  expanded.  Direction  of  these  changes  is 
provided  by  the  SDT  executive  director  programs.  These  same 
programs  are  used  in  selecting  and  generating  output  data. 
Five  different  formats  for  outputting  the  data  will  be 
available:  specialized  SDT  lists,  standard  SDT  lists,  block 
diagrams,  output  formatted  for  input  into  other  ETES 
procedures,  and  output  formatted  to  correspond  to  the  format 
requirements  of  specific  acquisition  documents. 

4.5  MODES  OF  OPERATION  FOR  PRIMARY  USERS  AND  DATA  BASE 
DIRECTORS 


This  section  describes  the  different  modes  of  operation  that 
will  be  available  to  the  primary  users  and  Data  Base 
Directors.^  The  SDT  will  have  five  primary  modes  of 
operation:  sign-on/status  check,  system  examination,  input, 
update/modify,  and  output.  System  examination  will  display 


2  The  modes  of  operation  for  the  SDT  Management  Group,  who 
will  be  concerned  with  software  development  and  maintenance, 
will,  of  course,  be  much  more  complex. 
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selected  data  in  the  SDT  data  base.  The  Input  mode  is  used 
to  input  data  to  the  SDT  data  base.  The  Update/Modify  mode 
is  used  to  change,  replace,  or  delete  existing  data  in  the 
SDT  data  base.  Output  is  used  to  obtain  a  printed  copy  of 
selected  data  from  the  SDT  data  base. 

The  user  entering  the  system  sign-on/ status  check  mode,  will 
be  able  to  select  the  mode  of  operation  he  would  like  to 
begin  with.  As  he  progresses  through  transactions,  he  may 
proceed  to  different  modes  in  an  alternating  fashion.  The 
classification  of  transactions  into  modes  facilitates  the 
sequencing  of  the  transaction  frames  which  will  lead  the 
uninitiated  user  through  the  SDT.  More  details  on  these 
different  modes  of  operation  are  provided  in  the  sections 
which  follow. 

4.5.1  Sign-On/System-Status  Check 

This  is  the  first  mode  of  operation  for  every  user.  During 
this  mode  of  operation,  the  user  is  provided  with  (1) 
references  for  obtaining  a  detailed  description  of  the  SDT, 

(2)  a  general  overview  of  the  items  that  are  currently  in 
the  data  base  for  the  system  in  which  he  is  interested,  and 

(3)  a  general  description  of  the  updates,  modifications,  and 
additions  to  the  data  base  that  have  occurred  since  he  last 
utilized  it. 

After  the  sign-in/system  status  check,  the  user  will  be 
provided  with  an  opportunity  to  select  which  of  the 
remaining  four  modes  of  operation  he  would  like  to  enter 
first. 
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4.5.2  System  Examination 


During  this  mode  of  operation,  the  user  can  examine  data 
which  is  currently  in  the  data  base.  In  conducting  this 
examination,  the  user  will  have  the  option  of  either 
selecting  from  a  predetermined  set  of  information  or  being 
led  through  the  data  in  top-down  hierarchical  fashion  to 
examine  specific  elements  within  a  class  of  information.  In 
the  latter  approach,  he  will  be  presented  with  a  menu  of  the 
items  at  each  level  in  the  hierarchy  and  he  will  be  asked  to 
select  which  item  in  the  menu  he  would  like  to  examine  in 
more  detail  in  the  next  frame.  When  the  user  is  finished 
going  down  a  branch  as  far  as  he  would  like  to  go,  he  can 
start  over  again  at  the  top  of  the  hierarchy. 

4.5.3  Input  Mode 

This  mode  of  operation  refers  to  interactive  input  only. 
Thus,  in  the  first  frame,  the  user  will  be  told  that  he  can 
only  input  data  interactively  and  that  if  he  wants  to  enter 
batch  data  he  must  do  so  by  sending  his  data  to  the  DBDs  or 
SDT  Management  Group  who  will  have  batch  capabilities.  To 
input  data  the  user  will  be  presented  with  a  list  of  the 
possible  input  formats  he  may  use  and  he  will  be  asked  to 
select  a  format.  The  selected  format  will  then  appear  on 

the  screen  and  he  will  begin  to  fill  in  the  necessary  data 

(as  many  of  the  data  elements  as  possible  will  be  filled  in 
automatically  by  the  SDT).  When  he  has  completed  one 
format,  the  next  format  will  appear  on  the  screen  and  he 
will  fill  that  in,  etc.  Wtien  he  has  completed  inputting  the 

information,  the  SDT  will  check  his  information  for 

consistency  with  existing  data  and  the  SDT  conceptual  model. 
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The  user  will  then  be  asked  to  correct  his  errors.  When 
all  errors  have  been  corrected,  the  user  will  be  presented 
with  a  summary  of  the  input  data  he  has  developed  and  he 
will  be  asked  if  he  wants  to  place  these  information 
elements  into  permanent  storage  in  the  DBMS.  If  he  does, 
the  system  will  then  determine  if  the  user  has  been  cleared 
to  store  data  of  that  type.  If  he  does  have  clearance,  this 
information  is  stored.  If  he  doesn't  have  this  capability, 
the  user  is  recommended  to  go  to  the  output  mode  to  receive 
a  hard  copy  of  his  data  and  to  call  the  DBD  to  clarify  his 
role . 

The  input  mode  is  used  to  add  information  to  the  DBMS  for 
specific  entities.  There  will  be  a  separate  data  input 
sheet  for  each  entity  and  different  types  of  input  sheets 
for  the  different  classes  of  entities.  If  the  user  wants  to 
change  information,  he  is  directed  to  enter  the  update/ 
modify  mode. 

4.5.4  Update/Modify  Mode 

During  this  mode  of  operation,  the  user  may  (1)  eliminate  a 
complete  entity  and  its  corresponding  attributes  (i.e.,  a 
single  input  worksheet),  {2)  eliminate  an  entire  class  of 
entities,  (3)  eliminate  an  attribute  value  on  a  specific 
datasheet,  and  (4)  replace  an  attribute  value  with  another. 

Again  the  method  for  making  these  updates  and  modifications 
will  be  based  on  a  top-down  hierarchical  approach  in  which 


^  If  inconsistencies  still  existed  between  data  in  the  data 
base  and  input  data,  the  user  would  be  asked  to  call  the  DBD 
for  instruction. 
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the  user  will  use  menu-selection  to  select  items  and  work 
his  way  down  a  hierarchy  until  he  has  reached  a  specific 
entity.  At  that  point,  the  worksheet  associated  with  that 
entity  will  be  placed  on  the  screen  and  the  user  can  make 
the  appropriate  modifications  and  updates. 

4.5.5  Output  Mode 

In  this  mode  the  user  selects  what  data  he  would  like  to 
have  outputted  and  the  type  of  output  he  would  like  to 
obtain.  The  user  will  have  two  options  for  selecting  the 
data  elements  he  wishes  to  output.  First,  he  can  select  a 
report  type  from  among  a  standardized  set  of  common  output 
report  formats  (this  will  be  the  quickest  way  to  obtain 
output  data).  Second,  he  can  elect  to  output  data  he  has 
worked  with  or  developed  in  the  previous  modes.  Mere 
specifically,  he  can  have  outputted  all  the  data  he  examined 
during  the  examination  mode,  all  the  data  he  input  during 
the  input  mode,  and/or  all  of  the  data  sheets  associated 
with  the  data  elements  he  modified  or  updated  during  the 
modify/update  mode. 

Five  different  types  of  output  formats  will  be  available: 
(1)  specialized  SDT  output  that  describe  the  subsets  of  data 
examined,  input,  or  modified  by  the  user;  (2)  standard  SDT 
outputs;  (3)  block  diagrams  (hierarchical  activity  flow  and 
information  flow);  (4)  specialized  output  formats  tailored 
to  produce  output  in  a  form  which  is  congruent  with  the 
input  data  requirements  of  other  ETES  technologies  (e.g., 
the  simulation  models);  and  (5)  specialized  output  formats 
tailored  to  produce  output  in  a  format  which  is  congruent 
with  the  input  data  requirements  of  other  analyses  in  the 
acquisition  process  (e.g.,  the  LSAR). 
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Primary  users  will  not  be  able  to  directly  obtain  block 
diagrams  at  their  terminal  sites  since  they  may  not  have 
graphics  capabilities.  However,  they  can  receive  the  block 
diagrams  from  the  DBD  or  the  SDT  Management  Group  who  will 
have  a  graphics  capability  for  producing  block  diagrams. 

4.6  OVERVIEW  OF  SDT  OPERATION 

The  SDT  will  utilize  three  general  types  of  human-computer 
dialogue  formats  in  transactions  with  primary  users  and  the 
DBDs  :  menu  selection,  form-filling,  and  question-and- 
answer.  Form-filling  will  be  used  as  the  primary  mechanism 
for  inputting,  updating,  and  modifying  data.  Menu  selection 
will  be  used  as  the  means  for  systematically  searching 
through  the  SDT  data  to  select  data  for  examination, 
update/modification,  and  output.  Question-and-answer  will 
only  be  used  in  a  small  number  of  situations  where  there  are 
questions  involving  a  fairly  well-defined  answer  space 
(a.g.,  how  many  input  sheets  do  you  want  to  enter).  A  more 
detailed  description  of  the  operation  of  the  SDT  is 
presented  in  the  section  which  follows. 

4.7  EXAMPLE  INTERACTIONS 

To  provide  the  reader  with  a  more  concrete  picture  of  the 
operation  of  the  SDT,  th^s  section  provides  a  detailed 
description  of  the  types  of  interactions  that  are  likely  to 
occur  under  each  of  the  five  modes  of  operation  (sign- 
on/status  check;  system  examination;  input;  update/modify; 


*  The  SDT  Management  Group  is  expected  to  be  able  to  use 
more  sophisticated  dialogue. 
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and  output).  The  interactions  for  each  mode  of  operation  are 
presented  on  a  frame-by-frame  basis  where  each  frame  roughly 
corresponds  to  the  information  that  would  appear  on  the  CRT 
screen  at  a  single  point  in  time.  The  example  frames 
presented  in  this  section  are  not  meant  to  be  a  verbatim 
description  of  the  actual  frames  which  will  be  used  for 
SDT .  The  examples  simply  demonstrate  the  type  of 
information  that  can  be  expected  to  be  incorporated  in  the 
different  interaction  modes.  The  frames  are  frequently 
interspersed  with  comments  which  summarize  or  further 
explain  the  types  of  information  which  can  be  expected  to  be 
placed  on  each  sheet.  Figure  4-3  is  a  schematic 
representation  of  the  relationships  among  these  frames.  It 
represents  the  structure  of  the  automated  SDT. 
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FIGURi  4  3  SCHEMATIC  REPRESENTATION  OF  SOT  FRAMES 


Frame  1-1 


Mode :  Sign-On/Status  Check 

Title:  Introduction  to  SDT 


Welcome  to  the  System  Description  Technology  (SDT).  This 
SDT  is  an  automated  tool  for  describing  actual  and  projected 
elements  including  functional  requirements,  design  concepts, 
tasks,  skills,  training  program  elements  and  their 
associated  resources. 

You  should  not  attempt  to  use  the  SDT  until  you  have  read 
the  SDT  users  manual.  You  may  obtain  a  manual  from  the  SDT 
Management  Group  which  is  located  at  (autovon)  or  the  data 
base  director  for  your  system  (  ) . 

If  you  have  any  questions  about  the  use  of  the  SDT  at  any 
time,  please  feel  free  to  call  the  SDT  Management  Group  or 
your  data  base  director. 


(User  would  continue  on  to  frame  1-2) 
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Mode :  Sign-On/Status  Check 
Title:  System  Selection 


Frame  1-2 


Listed  below  are  the  systems  which  currently  have  an  SDT 
data  base.  Please  type  in  the  number  of  the  system  you 
would  like  to  work  with. 


1. 

XXX 

6. 

XXX 

2. 

XXX 

7. 

XXX 

3. 

XXX 

8. 

XXX 

4. 

XXX 

9. 

XXX 

5. 

XXX 

10. 

XXX 

Number 

(User  would  continue  on  to  frame  1-3) 
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M°de :  Sign-On/Status  Check 
Titles  System  Status 


Frame  1-3 


Listed  below  are  the  systems  which  are  currently  in  the  data 
base  for  your  system  and  the  elements  which  have  been  added 
or  modified  since  your  last  interaction  with  the  SDT . 


System 


Person 
Making  Last 
Transaction 


Date  of 
Last 

Transaction 


Items  Added 
Modified  Since 
Your  Last 
Transaction 


1. 

2. 

3  . 

4. 

5. 

6. 

7. 

8. 
9* 
10. 


(User  would  continue  on  to  frame  1-4) 
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Mode :  Sign-On/Status  Check 
Title:  Mode  Selection 


Frame  1-4 


The  SDT  has  four  modes  of  operation: 

1.  System-Examination:  This  mode  is  used  to  examine  data 
which  is  currently  in  the  data  base,  etc.  (see  page  __  ) 

2.  Input:  This  mode  is  used  to  input  data,  etc.  (see 

page  _) . 

3.  Update/Modify :  This  mode  is  used  to  eliminate  or 

modify  data  already  in  the  data  base,  to  replace 
obsolete  or  incorrect  data  values,  etc.  (see  page  ) . 

4.  Output:  This  mode  is  used  to  obtain  a  hard  copy  output 
of  elements  in  the  SDT  (see  page  __) . 

5.  st°P;  I  am  finished  using  the  SDT. 

Please  type  in  the  number  of  the  mode  of  operation  you  would 

like  to  use  first.  Unless  you  have  something  fairly 

specific  in  mind,  you  probably  want  to  start  with  a  system 

examination  (Mode  1). 

Number 


(User  would  go  to  frame  1-5) 


Mode ;  Sign-On  Status  Check 
Title:  Mode  Control 


Frame  1-5 


Before  entering  the  mode  you  have  chosen,  it  is  important  to 
point  out  that  you  can  use  the  following  commands  to  obtain 
immediate  withdrawal  from  a  mode  or  a  particular  interaction 
within  a  mode: 

BACK:  By  typing  in  this  command,  you  can  immediately  leave 
the  particular  set  of  transations  in  which  you  are  involved 
and  return  to  the  beginning  of  that  mode. 

WA  YBACK :  By  typing  in  this  command,  you  can  return  to  the 
mode  selection  option  and  select  a  new  mode. 

The  above  commands  are  only  necessary  when  you  want  to 
interrupt  the  normal  flow  of  the  SDT  transactions.  If  you 
do  not  interrupt,  you  will  automatically  be  given  a  chance 
to  enter  another  mode  when  you  have  completed  your 
transactions  in  the  current  mode  you  have  selected. 

(User  would  go  to  the  first  frame  of  the  mode  he  selected) 
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Mode :  System  Examination 

Title:  Selection  of  Entity 


Frame  2-1 


Listed  below  are  system  elements  currently  in  the  data  base 
for  your  system.  Please  type  in  the  number  of  the  system 
element  you  would  like  to  examine  first. 


System 

Element 


Person 
Making  Last 
Transaction 


Date  of 
Last 

Transaction 


Items  Added 
or  Modified 
Since  your 
Last 

Transaction 


Associated 
Design  Alter 
native(s) 


1.  Functional 
Requirements 

2. 


3. 


4. 


5.  Tasks 


(Assume  that 
user  types  in 
No.  5:  Tasks) 


(User  would  go  to  frame  2-2) 


Mode !  System  Examination 
Title2  Selection  of  Subset  Type 


Frame  2-2 


Tasks  may  be  grouped  in  several  different  ways.  Listed 
below  are  the  ways  in  which  tasks  may  be  grouped  for 
examination  in  the  SDT .  Please  type  in  the  number  of  the 
way  in  which  you  would  like  the  tasks  grouped  for 
examination. 

1.  Tasks  by  general  task  type  (operator  tasks,  maintenance 
tasks,  support  tasks) 

2.  Task  by  MOS  and  duty  position 

3. 

4.  Tasks  by  equipment 

5. 

6.  Tasks  by  equipment  and  task  type 

7. 


(Assume  the  user  types  in  "6"  indicating  that  he  wants  tasks 
by  equipment  and  by  task  type.) 

Listed  below  are  the  current  design  alternatives.  Please 
type  in  the  number  of  the  design  alternative  for  which  you 
would  like  to  examine  the  above  information. 

1  5 

2  6 

3  7 

4 

Number _ 

(User  would  go  to  f-ame  2-3) 
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Mode :  System  Examination 

Title5  Selection  of  Special  Subset 


Frame  2-3 


You  have  chosen  to  examine  tasks  by  equipment  and  task  type. 
Listed  below  are  the  hardware  subsystems  and  the  task  types 
which  are  currently  in  the  data  base  for  your  system. 
Please  type  in  the  numbers  of  the  equipment  and  task  types 
you  would  like  to  examine  in  the  spaces  provided  below. 


Equipment 

1.  All  subsystems 

2.  Fuel 

3.  Turret 

4.  Engine 

5. 

6. 

7. 

Equipment  Numbers 


Task  Types 

1.  All  tasks 

2.  Operator  task 

3.  Maintainer  task 

4.  Support  tasks 


Task  Type  Numbers _ 

(assume  user  types  in  1  for  equipment  and  3  for  task  types) 
(User  would  go  on  to  frame  2-4) 
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Mode !  System  Examination  Frame  2-4 

Title:  Display  Selection 


Listed  below  are  the  maintenance  tasks  for  all  of  the 
equipmeat  subsystems. 


(User  would  go  on  to  frame  2-5) 
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Mode  s  System  Examination 
Title:  Output 


Frame:  2-5 


Do  you  want  a  printed  output  of  the  information  you  have 
just  examined? 

1 .  yes  2 .  no 

The  computer  will  remember  that  you  want  an  output  of  this 
infomation.  You  may  continue  to  examine  additional  system 
elements.  When  you  have  completed  your  examinations,  you 
can  enter  the  output  mode  and  have  this  and  any  other  system 
information  you  have  examined  printed  out  in  a  hard  copy. 
Or  you  can  enter  the  output  mode  and  obtain  a  printed  output 
immediately. 


(User  would  continue  on  to  frame  2-6) 
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Frame  2-6 


Mode :  System  Examination 

Title:  Reinitialization  of  System 


Do  you  want  to  continue  examining  system  elements  (that  is, 
to  stay  in  the  system  examination  mode). 

1.  yes  2.  no 

(If  the  user  typed  in  "1"  (yes),  he  would  be  sent  back  to 
frame  2-1  to  begin  the  examination  process  over.  If  the 
user  typed  in  ”2"  (no)  indicating  that  he  wanted  to  go  into 
a  new  mode  of  operation,  he  will  be  sent  back  to  frame  1-4 
to  select  another  mode  of  operation.) 


M°de :  Input 

Title:  Introduction 


Frame  3-1 


The  steps  which  follow  will  allow  you  to  input  data 
interactively  (that  is  directly  on  the  display  screen).  If 
you  want  to  enter  data  in  batch  mode  (that  is,  you  want  to 
fill  out  data  sheets  manually  and  submit  these  completed 
data  sheets  or  you  want  to  enter  data  which  is  already  on 
computer  cards  or  tape),  you  must  contact  the  data  base 
director  for  your  system  or  the  SDT  data  base  management 
group  and  make  arrangements  for  them  to  enter  this  data  into 
the  data  base  for  you. 

Remember,  this  mode  of  operation  can  only  be  used  to  add  an 
entire  data  sheet.  If  you  wish  to  add  an  item  to  a  data 
sheet,  you  should  enter  the  Update/Modify  node. 

Do  you  want  to  continue  in  this  mode? 

1 .  yes  2 .  no 

(If  he  types  “1"  (yes),  he  will  continue  on  to  the  next 
frame,  3-2.  If  user  types  “2M  (no),  he  is  sent  back  to 
mode-selection  frame,  1-4.) 
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M°de :  System  Input 

Titles  Selection  of  Data  Sheot 


Frame  3-2 


Listed  below  are  the  different  types  of  data  input  sheets 
which  are  used  in  the  SDT.  Please  type  in  the  number  of  the 
type  of  data  sheet  you  would  like  input  first. 

Data  Input  Sheet  Description 


1. 

2. 

3. 

4. 

5 . 

6. 

7. 

8.  Maintenance  task  lists 

9. 


(assume  the  user  typed  in  M8H,  indicating  he  wanted  to  input 
maintenance  task  lists). 


How  many  of  these  data  sheets  do  you  want  to  input? 
(User  types  in  number) 

(User  would  go  on  to  frame  3-3) 
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M°de :  Input 

Title:  Input  Directions 


Frame  3-3 


Before  inputting  data,  it  is  important  that  the  following 

guidelines  be  reviewed  (see  the  User  manual  for  a  more 

detailed  description). 

1.  If  you  make  a  mistake  in  inputting  data  on  a  sheet  and 
you  have  not  left  the  line  containing  the  incorrect 
information,  you  can  correct  the  error  by  backspacing 
and  typing  in  the  line  again. 

If  you  have  left  the  line  with  the  incorrect 
information,  you  cannot  correct  the  data  in  the  input 
mode.  You  must  continue  and  go  into  the  update/modify 
mode  later  to  correct  your  errors.  You  can,  however, 
eliminate  the  entire  input  sheet  by  typing  in  —  at  any 
time. 

2.  You  do  not  have  to  fill  out  all  of  the  items  in  the 
data  input  sheet.  Fill  out  as  many  items  as  you  can. 
You  will  have  an  opportunity  to  add  to  the  data  sheets 
later. 

3.  The  data  input  sheets  will  often  have  a  listing  of 
possible  answers  and/or  a  range  of  legitimate  values 
for  many  of  the  data  items. 

4.  To  obtain  additional  guidance  in  filling  out  the  data 
sheets,  particularly  in  using  output  from  other  parts 
of  the  data  base  to  help  you  fill  out  information, 
please  see  your  manual,  section 

(User  would  continue  on  to  frame  3-4) 
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Mode:  Input 

Title:  Data  Input  Sheets 


Frame  3-4 


(The  user  would  now  be  presented  with  a  formatted  data  input 
sheet  which  he  would  fill  in.  When  he  reached  the  end, 
another  sheet  would  appear  and  he  would  type  in  the 
information  for  the  next  sheet,  etc.  User  would  eventually 
go  on  to  Frame  3-5.) 
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Mode :  Input 

Title:  Select  Input  Mode 


Frame  3-5 


You  have  just  completed  filling  out  your  xxx  sheet.  Please 
type  in  the  number  of  the  action  you  would  like  to  take 
next . 

1.  Input  more  data  input  sheets  of  this  type 

2.  Input  another  type  of  data  input  sheet 

3.  Go  into  another  mode  of  operation. 

(If  the  user  typed  in  "1"  he  would  be  asked  how  many  more 
sheets  he  wanted  to  type  in  and  then  he  would  be  presented 
with  the  sheets.  If  he  typed  in  "2",  he  would  go  to  frame 
3-6.  If  he  typed  in  "3",  he  will  also  be  sent  to  frame  3- 


Mode :  Input 

Title:  Storage 


Frame  3-6 


Do  you  wish  to  store  the  data  items  you  have  input? 

1.  yes  2.  no 

(If  user  answers  yes,  the  system  will  check  to  see  if  the 
user  has  been  cleared  to  store  data  of  that  type.  If  he  has 
not  been  cleared,  a  message  will  appear  on  the  screen 
telling  the  user  that  he  has  not  been  cleared  to  modify  and 
store  data  of  that  type  and  he  will  be  asked  to  contact  his 
data  base  director  or  the  SDT  Management  Group.  If  he  is 
cleared,  and  his  data  has  been  stored,  he  will  be  told  he 
has  been  cleared  and  sent  to  frame  3-7.) 
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Mode :  Input 

Title:  output 


Frame  3-7 


Do  you  want  a  printed  output  of  the  input  data  sheets  you 
have  just  examined? 

1.  yes  2.  no 

Do  you  want  to  input  more  data? 

1 .  yes  2 .  no 

(After  typing  "1"  or  "2"  to  the  second  question,  the  user 
would  be  sent  either  to  frame  3-2  if  he  indicated  he  wanted 
to  input  more  data  or  Lo  frame  1-4  if  he  indicated  he  wanted 
to  enter  another  mode.  (Assume  user  typed  in  "1"  (yes)  for 
both  questions.) 

The  computer  will  remember  that  you  want  an  output  of  this 
information.  You  may  continue  to  input  additional  system 
elements.  When  you  have  completed  inputting  data,  you  can 
enter  the  output  mode  and  have  this  and  any  other 
information  you  have  input  printed  out  in  hard  copy. 
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Frame  4-1 


Mode :  Update/Modify 

Title:  Introduction 

This  mode  will  allow  you  to  (1)  replace  the  current  value  of 
an  item  in  an  existing  input  sheet  with  another  value,  (2) 
eliminate  an  entire  input  sheet,  (3)  eliminate  data  items  in 
a  data  sheet,  (4)  eliminate  a  system  element  and  all  of  its 
associated  data  (e.g.,  eliminate  a  subsystem  and  all  data 
collected  with  it),  and  (5)  change  the  name  of  a  particular 
data  item. 

Note:  If  you  want  to  add  an  entire  input  sheet  you  must 

enter  the  input  mode  to  do  so. 

Please  type  in  the  number  of  the  modification  you  want  to 
make. 


1.  Replace  the  current  value  of  an  item  in  an  existing 
input  sheet  with  another  value 

2.  Eliminate  an  entire  input  sheet 

3.  Eliminate  data  items  in  a  data  sheet 

4.  Eliminate  a  system  element  and  all  of  its  associated 
data 

5.  Change  the  name  of  a  particular  data  item 
Number 


(If  the  user  types  in  "1",  "2",  or  "3",  he  is  sent  to  frame 
4-2?  if  he  types  in  "4"  he  is  sent  to  frame  4-3?  if  he  types 
in  *'5M,  he  is  sent  to  frame  4-7). 

(User  would  go  on  to  frame  4-2) 
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Mode :  Update/Modify 


Frame  4-2 


Title:  Selection  of  Sheets  I 

Do  you  have  a  specific  sheet  you  would  like  to  eliminate, 
update,  or  modify? 

1 .  yes  2 .  no 

If  "yes"  enter  the  numbers  of  those  sheets 

Numbers 

Numbers 

etc. 

(If  user  enters  "yes”,  the  identified  sheets  would  then 
appear  on  the  screen-as  in  frame  4-10  after  the  user  has 
answered  the  following  questions). 

Do  you  want  to  eliminate  any  input  sheets? 

1 .  yes  2 .  no 

(If  he  answered  "yes",  he  is  asked  the  question  which 
follows.  If  he  answers  "no",  the  specific  data  sheets  he  has 
chosen  to  update  and  modify  will  begin  appearing  on  the 
screen  as  in  frame  4-10). 

Enter  the  numbers  of  the  sheets  you  want  to  eliminate 

Number 

Number 

Number 

etc . 


(After  eliminating  sheets  or  updating  or  modifying  sheets, 
the  user  will  be  sent  to  frame  4-12) 
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Frame  4-3 


Mode :  Update/Modify 

Titles  Selection  of  Input  Sheet  Type 

Listed  below  are  the  different  types  of  input  sheets 
currently  in  the  system.  Please  type  in  the  number  of  the 
type  of  sheet  you  would  like  to  update/modify/eliminate 
first. 

Data  Input  Design  Currently 

Sheet  Description  Alternative  in  System  (X) 


1. 

2. 

3. 

4. 

5. 

6.  Tasks 
Number 


(Assume  the  user  types  in  "6") 
(User  would  go  on  to  frame  4-4) 
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Mode :  Update/Modify  Frame  4-4 

Title:  Selection  of  Sheets  II 


Do  you  want  to  update,  modify,  or  eliminate  all  the  task 
data  sheets? 

1 .  yes  2 .  no 

(If  he  answers  "yes",  then  the  input  data  sheets  of  that 
type  will  start  appearing  on  the  screen  one  right  after 
another  as  in  frame  4-11.  If  he  answers  "no",  he  is  sent  to 
frame  4-5,  which  will  direct  him  to  search  through  the  data 
and  select  the  subset  of  input  data  sheets  within  the  more 
general  type  he  would  like  to  update/modify/eliminate.  After 
all  of  the  relevant  data  sheets  have  been  modified  or 
updated,  the  user  will  be  sent  to  frame  4-12.) 
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Mode :  TJpdate/Modify  Frame  4-5 

Title:  Selection  of  Subset  Type  (example) 


Listed  below  are  the  different  ways  in  which  task  input  data 
sheets  may  be  grouped.  Please  type  in  the  grouping  related 
to  the  subset  you  would  like  to  modify /update  (for  example) 

1.  Tasks  by  general  task  type  (operational  tasks, 
maintenance  tasks,  support  tasks) 

2.  Tasks  by  MOS  and  duty  position 

3. 

4.  Tasks  by  Equipment 

5. 

6.  Tasks  by  Equipment  and  Task  Type 

(Assume  user  types  in  "6"  indicating  that  he  wants  to  group 
input  data  sheets  by  equipment  and  task  type). 

Listed  below  are  the  current  design  alternatives.  Please 
type  in  the  number  of  the  design  alternatives  for  which  you 
would  like  to  examine  the  above  information: 


1.  all  5. 

2.  6. 

3.  7. 

4.  B. 


Number 


(After  typing  in  the  number,  the  user  would  be  sent  to  frame 
4-6). 
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Mode :  Update/Modify 

Titles  Selection  of  Specific  Subset 


Frame  4-6 


You  have  chosen  to  group  tasks  by  equipment  and  task  type. 
Listed  below  are  the  hardware  subsystems  and  the  task  types 
which  are  currently  in  the  data  base  for  your  system* 
Please  type  in  the  numbers  of  the  equipment  and  task  types 
you  would  like  to  update/modify/eliminate  in  the  spaces 
provided  below. 


Equipment 

1.  All  Subsystems 

2.  Fuel 

3.  Turret 

4.  Engine 

5. 

6. 

Equipment  Numbers 
Task  type  Numbers 


Task  Types 

1.  All  tasks 

2.  Operator  tasks 

3.  Maintainer  tasks 

4.  Support  tasks 


Do  you  want  to  eliminate  all  of  the  data  input  sheets  in 
this  subset? 


1.  yes  2.  no 

(If  he  answers  “yes",  they  are  eliminated  and  he  is  sent 
back  to  frame  4-2.  If  he  answers  “no",  it  is  assumed  he 
wants  to  update/modify  the  individual  sheets  in  the  subset 
and  the  sheets  will  start  appearing  on  the  screen  as  in  4- 
10.  However,  as  each  input  data  sheet  appears  on  screen,  he 
will  be  given  an  opportunity  to  eliminate  it.  After 
modifying/  updating  the  individual  Input  data  sheets,  he  is 
sent  to  frame  4-12.) 
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Mode s  Update/Modify  Frame  4-7 

Titles  Changing  the  Name  Of  A  System  Element  -  Level  1 


If  you  want  to  change  the  name  of  a  particular  data  item, 
you  must  first  identify  the  class  of  data  items  of  which  it 
is  a  member.  Listed  below  are  the  different  types  of  data 
items  which  are  in  the  SDT.  Please  type  in  the  number  of 
the  type  of  data  item  whose  name  you  would  like  to  change. 

1.  Functions 

2.  System  Design  Concepts 

3 .  Tasks 

4. 


Listed  below  are  the  current  design  alternatives.  Please 
type  in  the  number  of  the  design  alternatives  for  which  you 
would  like  to  modify  the  name 

1  4 

2  5 

3  6 

Number 


(After  typing  in  the  number,  the  user  would  go  on  to  frame 
4-8.) 
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Please  type  in  the  ID  number  of  the  item(s)  whose  names  you 
would  like  to  change.  These  ID  numbers  can  be  obtained  by 
examining  the  input  data  sheets  associated  with  the  system 
elements. 

Numbers 

1 

2 

3 

4 


5 

6 

7 

8 

(After  filling  in  the  numbers,  the  user  would  go  on  to  the 
next  frame  4-9.) 
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Mode :  Update/Modify  Frame  4-9 

Titles  Changing  the  Name  of  System  Elements  -  Level  3 


Please  type  in  the  new  names  you  wish  to  use  for  the  current 
system  elements  listed  below. 

ID  Number  Current  Name  New  Name 

xxxxx  xxxxxxx 

etc. 

(After  completing  these  changes,  the  user  would  be  sent  to 
frame  4-12) 
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Mode :  Update/Modify  Frame  4-10 

Title:  Directions  for  Adding/Modifying  Data  Sheets 


You  can  add  or  modify  items  in  the  data  sheets  which  appear 
on  the  screen  by  (1)  skipping  to  the  line  you  want  to  modify 
using  the  line  advance  key  on  your  keyboard  and  (2)  typing 
in  (if  adding  a  new  item)  or  typing  over  (if  replacing  an 
existing  item)  the  appropriate  information  on  that  line. 

In  addition,  the  following  directions  can  aid  you  in 

inputting  data: 

1.  If  you  make  a  mistake  in  inputting  data  on  a  sheet  and 
you  have  not  left  the  line  containing  the  incorrect 
information,  you  can  correct  the  error  by  backspacing 
and  typing  in  the  line  again. 

If  you  have  left  the  line  with  the  incorrect 

information  you  cannot  correct  the  data  in  the  input 
mode.  You  must  continue  and  go  into  the  update/modify 
mode  to  later  correct  your  errors.  You  can,  however, 
eliminate  the  entire  input  sheet  by  typing  in  at  any 

time. 

2.  You  do  not  have  to  fill  out  all  of  the  items  in  the 
data  input  sheet.  Fill  out  as  many  items  as  you  can. 
You  will  have  an  opportunity  to  add  to  the  data  sheets 
later. 

3.  The  data  input  sheets  will  have  a  listing  of  possible 
answers  and/or  a  range  of  legitimate  values  for  many  of 
the  data  items. 

4.  To  obtain  additional  guidance  in  filling  out  the  data 

sheets,  particularly  in  using  output  from  other  parts 
of  the  data  base  to  help  you  fill  out  information, 
please  see  your  users  manual,  section _ . 

(User  would  be  sent  to  frame  4-11) 
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Frame  4-11 


Mode :  Update/Modify 

Title:  Data  Sheets 


(The  user  would  now  be  presented  with  the  data  sheets  which 
he  had  selected  to  update  or  modify.  When  he  completed  one 
sheet,  another  sheet  would  appear.  After  the  final  one,  he 
would  go  on  to  frame  4-12). 
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Mode :  Update/Modify 

Title:  Output 


Frame  4-12 


Do  you  want  a  printed  output  of  the  input  data  sheets  you 
have  just  modified  or  updated? 

1 .  yes  2 .  no 

(Assume  user  answered  "yes".) 

The  computer  will  remember  that  you  want  an  output  of  this 
information.  You  may  continue  to  input  additional  system 
elements.  When  you  have  completed  inputting  data,  you  can 
enter  the  output  mode  and  have  this  and  any  other 
information  you  have  input  printed  out  in  hard  copy. 

(After  answering  this  question,  the  user  will  be  sent  to 
frame  4-13) 
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Mode :  Update/Modify 

Title:  Impacts 


Frame  4-13 


Do  you  wish  to  see  what  other  data  input  sheets  are  impacted 
by  the  changes  you  have  made?  It  is  highly  recommended  that 
you  consider  these  impacts. 

1.  yes  2.  no 

(If  user  answers  "no",  he  is  sent  to  the  next  frame.  If  he 
answers  "yes",  the  following  information  appears  on  the 
screen. ) 

Listed  below  are  the  data  input  sheets  which  are  impacted  by 
the  changes  you  have  made. 


Data  Data 

Sheet  Elements  Sheet  Number  of  Modified 

Type  Number  Impacted  Sheet  Producing  Change 


(After  viewing  this  information,  the  user  is  sent  to  the 
next  frame,  4-14) 


4-50 


Mode :  Update/Modify 

Title:  Reinitialization  of  System 


Frame  4-14 


Do  you  want  to  continue  in  the  update/modify  mode? 

1.  yes  2,  no 

(If  user  answers  "yes"  he  is  sent  back  to  frame  4-1.  If  he 
answers  "no"  he  is  sent  to  frame  4-15.) 
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Mode :  Update/Modify 

Title:  Storage 


Frame  4-15 


Do  you  wish  to  store  the  data  items  you  have  changed? 

1.  yes  2.  no 

(If  user  answers  "yes",  the  system  will  check  to  see  if  user 
has  been  cleared  to  store  data  of  that  type.  If  he  has  not, 
a  message  will  appear  on  the  screen  telling  the  user  that  he 
has  not  been  cleared  to  modify  and  store  data  of  that  type 
and  he  will  be  asked  to  contact  the  data  base  director  or 
the  SDT  management  group.  If  he  answers  "no",  he  will  be 
sent  to  frame  1-4.) 
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Mode :  Output 

Title:  Introduction 


Frame  5-1 


The  SDT  can  provide  five  major  types  of  output: 

1.  Specialized  SDT  output  -  These  are  specialized  output 

reports  that  you  may  have  constructed  in  examining  the 
system  (Mode  1),  inputting  data  (Mode  3),  or 
updating/modifying  the  system  (Mode  4).  These 

specialized  reports  allow  you  to  examine  the  specific 
subsets  of  information  you  chose  to  examine,  the  input 
data  sheets  you  have  just  entered  into  the  system,  or 
the  data  sheets  you  have  just  updated  or  modified.  (If 
you  have  indicated  you  wanted  output  in  previous  modes, 
you  must  select  this  option  to  obtain  that  output.) 

2.  Standard  SDT  Outputs  -  The  SDT  has  a  series  of  standard 
reports  for  representing  the  types  of  data  that  users 
are  most  likely  to  request.  If  you  are  in  doubt  as  to 
what  type  of  output  you  want,  it  is  recommended  that 
you  select  this  option. 

3.  SDT  Block  Diagrams  -  The  SDT  has  the  capability  of 
printing  out  block  diagrams  for  selected  types  of 
system  relationships.  The  type  of  block  diagrams  which 
are  available  are  (1)  hierarchical  block  diagrams  for 
representing  hierarchical  relationships  among  system 
elements,  (2)  activity  flow  diagrams  for  representing 
sequential  relationships  between  system  elements  or 
functions,  and  (3)  information  flow  diagrams  for 
representi.in  the  flow  of  inputs  and  outputs  among 
system  elements. 
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Mode :  Output 

Title:  Introduction 


Frame  5-1  (cont.) 


You  may  not  have  the  capability  for  obtaining  block 
diagrams  on  your  system.  If  you  select  this  option  and 
do  not  have  a  block  diagram  capability,  your  output 
will  be  sent  to  either  the  DBD  or  SDT  Management  Group, 
who  will  in  turn  send  it  to  you  at  a  later  date. 

4.  ETES  Formatted  Output  -  The  SDT  has  the  ability  to 
produce  output  data  in  formats  which  are  congruent  with 
the  input  requirements  of  other  ETES  tools. 

5.  Acquisition  Document  Formatted  Output  -  The  SDT  has  the 
ability  to  output  data  in  formats  which  are  congruent 
with  selected  Army  acquisition  documents. 

(User  would  be  sent  to  frame  5-2) 
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Mode :  Output 

Title:  Selection  of  Output  Formats 


Frame  5-2 


Listed  below  are  the  output  reports  that  are  available.  Type 
in  the  numbers  of  the  output  reports  you  want. 


Specialized  Output  Data 

1.1  Examined  Duty 

1.2  Input  Data 

1.3  Modified  Data 

1.4 


Standard  SDT  Data 

2.1  Tasks  by  MOS,  Duty 
Position 

2.2 

2.3 


2.4 


ETES  Formatted  Outputs 

4.1 

4.2 

4.3 


Acquisition  Doc  Formatted 
Outputs 

5.1 

5 . 2 

5.3 

5.4 


Block  Diagrams  (please  se 
diagram  you  want) 

3.1  Hierarchical 

3.2  Activity  Flow 

3.3  Information 


lect  a  number  and  a  letter  for  each 

A.  Functions 

B.  Design  Concepts 

C.  Tasks 


D. 


Numbers 

Selected _ 

(user  would  be  sent  to  frame  5-3) 
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Mode :  Output  Frame  5-3 

Title:  Selection  of  Alternatives 


below  are  the  maior  design  alternatives  for  your 

system. 

1. 

2. 

3. 

4. 


Listed  below  are  the  outputs  you  have  selected.  For  each 
output,  please  type  in  the  number  associated  with  the  design 
alternatives  for  which  you  would  like  to  see  the  designated 
ouput. 


IP  Number  of  Design  AlternativeC s)  You 
Output  Would  Like  To  See  Output  For 


(User  would  be  sent  to  frame  5-4.) 
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Mode :  Output 

Title:  Output  Location 


Frame  5-4 


Unless  otherwise  specified,  the  SDT  will  print  all  data  on 
your  printer  except  for  block  diagrams;  which  you  mus L  have 
outputted  at  the  DBD  or  SDT  Management  Group  facilities. 

In  the  spaces  provided  provided  below,  please  type  in  the 
number  of  the  additional  location  (DBD,  SDT  Management 
Group,  or  other)  where  you  would  like  to  have  your  reports 
outputted.  If  you  are  happy  having  the  reports  outputted  on 
your  printer,  you  can  leave  the  space  blank.  However,  if 
you  are  requesting  block  diagram  output,  you  must  specify 
where  you  would  like  the  diagrams  output.  The  codes  for 
location  sites  are: 


1.  Your  site 

2.  DBD  for  your  system 

3.  SDT  Management  Group 

4.  Other  (must  oe  prearranged  with  the  SDT  Management 
Group  before  attempting) 

In  addition  to  an  alternative  location,  you  may  also  want  to 
specify  an  alternative  medium  for  outputting  your  data  such 
as  tapes  or  discs.  Also  in  the  spaces  provided  below  please 
write  down  the  number  of  the  alternative  medium  on  which  you 
would  like  to  have  your  output  listed  using  the  following 


code: 

1. 

Tape 

2. 

Disc 

3. 

Card 

4.  Other  (must  be  prearranged  with  SDT  Management  Group) 
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Mode :  Output 

Titles  Output  Location 


Frame  5-4  ( cont . ) 


If  you  are  happy  with  your  printer  as  an  output  medium  you 
do  not  have  to  type  in  anything.  Do  not  attempt  to  an 
output  medium  with  a  site  unless  you  are  absolutely  certain 
that  the  site  has  the  capabilities  for  that  medium  and  has 
been  warned  of  your  use. 

Output  Alternatives  Location  Number  Medium  no. 
(User  would  continue  onto  frame  5-5.) 
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Mode ;  Output 
Titles  Output 


Frame  5-5 


(At  this  point#  the  user  would  receive  the  printed  output  he 
requested.  The  block  diagrams  would  be  output  at  the  DBD  or 
SDT  management  group's  facilities.  The  user  would  have  the 
capability  of  interrupting  the  output  at  any  time  by 
pressing  a  — #  in  which  case  frame  5-6  would  appear  on  the 
screen.  If  he  did  not  interrupt#  5-6  would  appear  when  he 
finished . ) 
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Mode :  Output 

Titles  Reinitialization  of  System 


Frame  5-6 


Do  you  want  to  continue  in  the  output  mode? 

1.  yes  2.  no 

(If  he  enters  “yes"  (1),  he  is  sent  to  frame  5-1.  If  he 
enters  "no"  (2),  he  is  sent  to  frame  1-4.) 
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4.8  INITIAL  VERSION  OF  SDT 


The  previous  subsections  outlined  the  features  of  the 
complete  SDT.  This  system  is  designed  to  provide  an  optimal 
tool  for  meeting  all  of  the  SDT  requirements.  It  is 
unlikely  that  the  optimal  SDT  can  be  fully  developed  within 
the  confines  of  the  present  study.  Hence,  it  is  necessary 
to  identify  an  initial  SDT  which  can  be  used  to  demonstrate 
the  SDT  capabilities  and  test  out  key  concepts  before  the 
optimal  SDT  is  constructed. 

More  details  on  the  characteristics  of  the  initial  SDT  are 
presented  in  the  subsections  whiv.h  follow. 

4.8.1  Characteristics  of  the  Initial  SDT 

The  initial  SDT  will  differ  from  the  final  SDT  in  four  major 
areas:  expected  users,  input  capabilities,  output 
capabilities,  and  the  range  of  system  items  to  be  described. 

4.8.2  Expected  Users 

For  the  development  of  the  initial  SDT,  the  contractor  (DRC) 
will  assume  the  role  of  both  data  base  director  and  SDT 
Management  Group.  Thus,  the  initial  SDT,  unlike  the  optimal 
version,  will  be  designed  for  two,  rather  than  thre*.,  user 
groups . 

4.8.3  Input  Capabilities  of  SDT 

The  final  SDT  will  have  the  capability  of  inputting  three 
different  types  of  data:  batch  input  of  SDT  data  sheets, 
interactive  input  of  SDT  data  sheets,  and  batch  input  of 
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related  data.  However,  the  initial  SDT  will  only  have  the 
capabilitv  for  interactive  input  of  SDT  data  sheets. 

4.8.4  -  Output  Capabilities  of  SDT 

The  final  SDT  will  have  the  capability  of  producing  five 
different  types  of  output:  (1)  Specialized  SDT  Output  for 
describing  subsets  of  data  examined,  inputted,  and 
modified/updated  by  the  user,  (2)  Standard  SDT  data  lists  — 
a  series  of  reports  listing  the  types  of  data  which  users 
are  most  likely  to  request,  (3)  SDT  Block  Diagrams,  (4)  ETES 
Formatted  Output,  and  (5)  Acquisition  Document  Formatted 
Output.  The  initial  SDT  will  only  provide  a  capability  for 
producing  (1)  the  Specialized  SDT  outputs  and  (2)  Standard 
SDT  data  lists. 

In  addition,  the  initial  SDT  will  not  have  the  capability  of 
outputting  data  to  tape,  disc,  or  alternative  media.  It 
will  only  have  the  capability  of  producing  standard  printed 
output. 

4.8.5  System  Elements  Described  in  SDT 

The  initial  SDT  will  attempt  to  describe  all  of  the  SDT 
system  elements  specified  in  Section  2.  However,  it  will 
not  be  possible  to  describe  all  of  the  elements  in  the 
initial  version  of  the  SDT.  The  schedule  for  including  the 
various  system  elements  in  the  SDT  will  follow  the 
priorities  outlined  in  Section  2.  It  may  not  be  possible  to 
complete  this  schedule  within  the  confines  of  the  present 
study.  In  that  case,  items  labelled  "priority  3"  may  not  be 
included  in  the  initial  SDT. 
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4.8.6  Other  Characteristics  of  the  Initial  SDT 


Because  it  is  the  "first  cut"  at  the  SDT,  the  initial  SDT  is 
also  likely  to  have  other  limitations.  First,  it  is  likely 
that  the  SDT  user  interface  will  not  be  as  smooth, 
efficient,  and  transparent  as  the  ultimate  SDT  interface. 
Second,  the  documentation  for  using  the  SDT  will  be  in  draft 
form  only  and  is  unlikely  to  be  as  comprehensive  as  the 
documentation  for  the  prototype.  This  draft  will  be 
constantly  updated  and  refined  as  the  study  progresses. 
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APPENDIX  A 


Review  of  Existing  Army  Procedures 

The  purposes  of  this  appendix  are  to  (1)  review  Army 
policies  and  procedures  for  mission  area  analysis  with 
particular  emphasis  on  those  policies  and  procedures  related 
to  early  training  estimation,  (2)  identify  the  deficiencies 
in  these  procedures  which  either  limit  or  inhibit  the 
effective  early  assessment  of  training  requirements,  and 
(3)  describe  the  role  of  ETES  correcting  these 
deficiencies. 

The  Appendix  is  divided  into  three  sections.  The  first 
section  provides  an  overview  of  the  Army  acquisition  process 
and  the  planning  and  decision  making  which  supports  this 
process. 

The  next  section  provides  a  review  of  mission  area  analyses 
including  a  detailed  description  of  the  policies,  procedures, 
decision  points,  and  a  description  of  the  potential  role 
of  ETES  in  correcting  some  of  the  current  deficiencies 
surrounding  this  period  of  the  acquisition  process.  This 
review  of  mission  area  analysis  procedures  updates  early 
reviews  of  the  Concept  Exploration  and  Validation  and 
Demonstration  Phases  of  the  acquisiiton  process  which  were 
presented  in  the  second  monthly  ETES  status  report. 


This  appendix  does  not  attempt  to  provide  a  detailed 
description  of  all  of  the  various  processes  and  documents 
associated  with  the  acquisition  process  -  rather  it  seeks  to 
highlight  those  processes  which  are  most  relevant  to  early 
training  estimation.  The  third  section  provides  a  detailed 
listing  of  Army  documents  relevant  to  these  processes. 
The  reader  seeking  more  detailed  information  is  urged  to 
consult  these  documents. 

A. 1  OVERVIEW  OF  THE  ARMY  ACQUISITION  PROCESS 


This  section  provides  an  overview  of  the  Army  acquisition 
process.  The  ultimate  objective  of  the  materiel  acquisition 
process  is  the  timely  delivery  of  an  operational  system 
which  effectively  meets  its  mission  at  minimum  cost  to  the 
Army.  As  used  here  the  term  "operational  system"  refers  to 
the  equipment,  software  support,  personnel  and  skills 
required  to  operate  and  maintain  the  equipment,  and  the 
support  systems  required  to  maintain  the  equipment  and 
personnel. 

The  major  Army  document  relating  to  the  materiel  acquisition 
process  is  the  Life  Cycle  System  Management  Model,  DA-PAM 
11-25.  The  Life  Cycle  Management  Model  (LSCMM)  describes  a 
series  of  events  which  may  be  used  by  the  program  manager 
for  an  emerging  system  to  guide  the  development  of  his 
system.  (The  reader  is  urged  to  examine  the  diagram  of  the 
LCSMM  events  contained  on  page  C-22  of  DA  PAM  11-25.)  It 
should  be  pointed  out  that  the  LCSMM  is  only  a  guide  and  the 
program  manager  has  a  fair  degree  of  freedom  to  delete  or 
modify  many  of  the  events  in  the  LCSMM.  This  tailoring  is 
seen  as  necessary  to  make  the  acquisition  process  responsive 
to  the  unique  needs  of  individual  programs. 
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The  Army  Weapons  Acquisition  Process  (AWSAP)  is  typically 
divided  into  four  phases:  (1)  Concept  Exploration;  (2) 
Demonstration  and  Validation;  (3)  Full  Scale  Development; 
and  (4)  Production  and  Deployment.  In  addition  to  these 
four  basic  phrases,  it  is  possible  to  add  another  "phase" 
(Phase  0)  to  represent  the  Mission  Area  Analysis  which  takes 
place  prior  to  concept  exploration.  Detailed  descriptions 
of  the  four  phases  are  described  in  LCSMM  Model  (DA-PAM  11-25) 
while  detailed  description  of  Mission  Area  Analysis  will  be 
described  in  a  soon  to  be  published  TRADOC  Handbook  on 
Mission  Area  Analysis. 

The  purpose  of  each  of  these  phases  is  described  in  Table  A- 
1.  Each  phase  is  terminated  by  a  Department  of  the  A.rmy 
and/or  DOD  decision  concerning  entry  into  the  next  phase  of 
development.  These  decision  points  are  milestones  0  thru  4 
of  the  acquisition  process. 

The  phases  of  the  AWSAP  provide  Army  Managers  with  the 
general  model  for  planning  and  decision-making  are  shown  in 
Figure  A-l .  Within  each  phase  of  the  acquisition  process 
work  progresses  in  defining  and  operationalizing  system, 
organizational,  operational,  and  support  concepts.  In  the 
early  phases  emphasis  is  placed  on  defining  the  system  and 
operational  concepts.  As  these  become  more  fully  defined 
the  emphasis  is  shifted  to  defining  and  operationalizing  the 
support  and  organizational  concepts.  Within  each  phase 
decision-making  and  planning  is  supported  by  the  testing  of 
the  high  risk  aspects  of  these  concepts.  These  test  results 
are  then  evaluated  and  this  information  influences  the 
program  planning  process.  The  planning  process  is  central 
to  a  successful  weapon  system  acquisition  program  and  allows 
the  acquisition  process  to  be  modified  to  the  particular 


Phase 


Purpose 


1.  Mission  Area  Analysis  *To  identify  those  mission  elements  for  which  existing 

or  projected  capability  is  deficient  and  to  identify 
opportunities  for  capability  enhancement  through 
more  effective  and  less  costly  methods  and  systems. 

2.  Concept  Exploration  * A'o  explore  and  identify  alternative  system  concepts. 


3.  Demonstration  and  **To  validate  the  selected  solution(s). 

Validation  Phase 


4.  Full-Scale 
Development 


**Devclop  a  pre-production  system  which  closely 
approximates  the  final  product. 


5.  Production  and 
Deployment 


**To  acquire  the  system  and  distribute  it. 


•ARA  1000-1  Basic  Policies  for  Systems  Acquisition. 

•♦DARCOM  TRADOC  Material  Acquisition  Handbook  (Advance  Copy). 


TABLE  A- 1 

The  purposes  of  the  AWSAP  phases. 


FIGURE  A  1  FLAMMING  AMO  OCCISIOM  MAKING  MODEL 


needs  of  each  specific  system.  This  planning  aspect  of  the 
AWSAP  results  in  the  differences  between  programs,  (e.g. 
Deletions  in  phases  and  activities  within  phases, 
differences  in  testing,  and  differences  in  timing  of 
activities . ) 

The  aspects  of  a  program  which  must  be  included  in  the 
planning  process  are  (1)  The  development  of  plans  for 
preparing  the  documents  required  to  support  the  decisions 
which  terminates  each  phase.  (2)  The  planning  of  the 
events  required  to  develop  the  information  which  will  be 
encluded  in  these  documents  (3)  Acquiring  the  necessary 
resources  to  accomplish  these  events  and  (4)  Identifying 
the  critical  Equipment,  Operational,  Organizational,  and 
Support  system  issues  for  test  and  evaluation. 

A. 2  PHASE  0 

A. 2.1  MISSION  AREA  ANALYSIS/MENS  DEVELOPMENT 

This  section  summarizes  the  role  of  Mission  Area  Analysis 
(MAA)  requirements  as  a  part  of  the  AWSAP  with  emphasis  on 
Manpower  and  Training  considerations.  MAA  takes  place  prior 
to  the  Milestone  0  and  is  one  of  the  major  activities 
related  to  the  development  of  the  Mission  Element  Need 
Statement  (MENS). 

Definitions  of  Mission  Analysis,  Mission  Area,  Mission 
Element,  the  MENS,  and  other  related  terms  are  presented  in 
the  sections  which  follow.  DODD  5000.1  (Major  Systems 
Acquisition),  revised  in  March  1980,  deleted  the  definitions 
of  Mission  Area  and  Mission  Element  previously  contained  in 
the  January  1977  edition  of  that  document.  Accordingly,  the 


former  directive  is  cited  as  the  basis  for  the  definition  of 
these  terms. 

A. 2. 1.1  Definitions  of  MAA  Terms 

Mission  Analysis  is  any  assessment  of  current  or  projected 
US  military  capability  to  perform  assigned  missions.  It 
normally  evaluates  the  interplay  of  threat,  capability, 
operations  concepts,  survivability,  and  other  factors  such 
as  environmental  conditions  which  bear  on  the  missions  of 
the  various  Components  of  the  Department  of  Defense.  The 
primary  objective  of  mission  analysis  is  the  identification 
of  deficiencies,  so  that  appropriate  corrective  action  can 
be  initiated.  (DODI  5000.2,  19  March  1980) 

Mission  Area  is  a  segment  of  the  defense  mission  as 
established  by  the  Secretary  of  Defense.  (DODD  500.1,  18 

January  1977) 

Mission  Element  is  a  segment  of  a  mission  area  critical  to 
the  accomplishment  of  the  mission  area  objectives  and 
corresponding  to  a  recommendation  for  a  major  system 
capability  as  determined  by  the  DoD  component.  (DODD 
5000.1,  18  January  1977) 

Mission  Element  Meed  Statement  (MENS)  is  the  document  upon 
which  the  Milestone  0  decision  is  based  (Table  A-2).  It 
identifies  and  defines:  (a)  a  specific  deficiency  or 

opportunity  within  a  mission  area;  (b)  the  relative  priority 
cf  the  deficiency  within  the  mission  area:  (c)  the  Defense 
Intelligence  Agency  (DIA)  validated  threat  forecast  or  other 
factor  causing  the  deficiency;  (d)  the  date  the  system  must 
be  fielded  to  meet  the  threat ;  and  (e)  the  general  magnitude 


Tabic  A-2 
OUTLINE  OF  MENS 


A.  Mission 

1.  Mission  Areas  -  mission  areas  addressed  by  MENS 

2.  Mission  Element  Need  -  nature  of  the  need  in  terms  of  mission 
capabilities. 

B.  Threat  or  Oasis  For  Need 

Basis  for  the  need  in  terms  of  an  anticipated  change  ir«  projected  threat, 
in  terms  of  exportable  technology  or  in  terms  of  nonthreat  factors. 

C.  Existing  and  Planned  Capabilities  to  Meet  the  Mission 

Summary  of  the  existing  and  planned  capabilities  to  accomplish  the 
mission. 

D.  Assessment  of  Need 

Evaluation  of  the  ability  of  current  and  planned  capabilities  to  cope 
with  the  projected  threat.  Thb  is  considered  to  be  the  most  important 
part  of  the  MENS.  The  evaluation  is  based  on  the  following  factors. 

1.  Deficiency  in  existing  capability 

2.  Exploitable  technological  opportunities 

3.  Force  size 

4.  Vulnerability  of  existing  systems 

E.  Constraints 

Identification  of  the  key  boundary  conditions  including : 

1.  Timing  of  need 

2.  Relative  priority  within  mission  area 

3.  Resources  required 

4.  Logistics,  safety,  health,  energy,  environment,  and  manpower  considerations 

5.  Standardization 

6.  Interfaces  with  other  systems 

F.  Resource  and  Schedule  to  Meet  Milestone 
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of  acquisition  resources  that  the  DoD  Component  is  willing 
to  invest  to  correct  the  deficiency.  (DODI  5001.1,  19  March 
1980) 


A. 2. 2  Mission  Area  Analysis  Initiation 

Mission  area  deficiencies  may  be  identified  at  any 
organizational  level  of  the  Army  structure.  Deficiency 
detections  in  this  category  would  normally  stem  from  the 
observations  of  unit  personnel  experiencing  the  impacts  of 
the  deficiencies  noted.  To  a  great  extent,  this  type  of 
mission  area  deficiency  is  correctable  by  direct  command 
action,  or  by  comparatively  minor  operational,  support 
and/or  equipment  program  modifications.  Mission  area 

deficiencies  resulting  in  the  acquisition  of  a  new  weapons 
system  usually  stem  from  a  change  in  the  threat  to  be 
countered,  or  from  revised  US  strategy.  A  major  change  in 
the  threat  may  be  identified  by  the  DIA,  or  via  the  Army's 
intelligency  activities  as  documented  formally  by  the 
Assistant  Chief  of  Staff  for  Intelligence  (ACSI),  Department 
of  the  Army. 

Long-range  US  military  objectives  and  capabilities  are 
documented  by  the  Joint  Chiefs  of  Staff  (JCS)  in  the  Joint 
Strategic  Objectives  Plan  (JSOP)  and  the  Joint  Strategic 
Capabilities  Plan  (JSCAP).  Army  implementation  of  the 
JSOP/JSCAP  is  published  in  the  Army  Strategic  Objectives 
Plan  (ASOP)  and  the  Army  Strategic  Capabilities  Plan 
(ASCAP).  These  Army  documents  are  updated  annually  under  the 
General  Staff  cognizance  of  the  Deputy  Chief  of  Staff  for 
Operations  and  Plans  (DCSOPS).  When  approved  by  the  Chief 
of  Staff  Army  (CSA),  the  ASOP  and  the  ASCAP  provide  the 
primary  basis  for  initiating  MAAs  within  the  Department  of 


Army  (DA)  General  Staff  and  Special  Staff,  and  within  major 
subordinate  commands  (e.g.,  DARCOM,  TRADOC),  to  identify  any 
deficiencies  in  the  Army's  capabilities  to  meet  near-term 
and  far-term  objectives. 

MAAs  resulting  in  the  acquisition  of  a  new  weapons  system 
may  also  be  initiated  to  establish  new  capabilities  in 
response  to  technologically  feasible  opportunities. 
Analysis  activities  included  under  MAA  occur  throughout  the 
lifecycle  of  a  weapon  system  and  MAA  has  a  continuing  inpact 
on  the  AWSAP .  Figure  A-2  shows  how  MAA  fits  into  the  Army's 
overall  force  need  identification  and  solution  development 
process.  MAA  does  not  necessarily  result  in  a  requirement 
for  a  new  materiel  acquisition.  Other  options  such  as 
building  the  technology  base,  changing  operational  concepts 
or  changing  organizational  concepts  can  also  be  used  to 
satisfy  a  mission  need.  However,  from  an  ETES  perspective 
only  mission  needs  which  generate  a  material  acquisition 
requirement  are  relevant. 

A . 2 . 3  MENS 

After  the  need  for  a  materiel  acquisition  is  identified,  an 
analysis  is  indicated  to  further  detail  this  need  and 
coordinate  the  development  of  the  materiel  system.  The 
results  of  this  analysis  are  documented  in  a  MENS  for  major 
systems  or  in  other  requirements  documents  (e.g.,  LOA)  for 
smaller  systems.  With  the  existing  deficiencies  identified 
the  technology  base,  existing  operational  concepts  and 
doctrine  and  organizational  concepts  are  reviewed  for 
possible  solutions.  Options  for  meeting  the  deficiencies 
are  identified  as  a  result  of  this  process.  These  options 
are  then  assessed  for  adequacy  in  the  content  of  the  updated 
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scenarios.  The  outputs  of  this  assessment  are  rank  ordered 
in  terms  of  their  ability  to  satisfy  the  mission  area  task 
or  subtask  requirement.  Along  with  this  rank  ordering  of 
options,  operational  and  technical  constraints  are  also 
identified. 

There  are  four  possible  options  for  meeting  a  battlefield 
deficiency  identified  during  MAA:  (1)  build  a  technology 
base,  (2)  change  the  existing  operational  concept,  (3) 
change  the  existing  organizational  concept  and  (4)  initiate 
a  materiel  acquisition.  Although  these  are  shown  as 
discrete  decisions  in  Figure  A-3,  actually,  these  four 
decisions  are  closely  intertwined.  This  interdependency  is 
a  primary  reason  for  the  continuing  interaction  between  the 
analysis  activities  supporting  organizational  and 
operational  concepts,  new  technology  development,  and  the 
development  of  a  new  materiel  system. 

Once  a  decision  is  reached  to  proceed  with  a  materiel 
acquisition,  a  management  plan  is  developed,  resource 
limits,  milestone  and  development  schedules,  and  resource 
requirements  are  identified.  The  information  developed 
during  this  analysis  is  then  used  to  develop  the  MENS. 
Figure  A-4  shows  the  relationship  between  the  MENS  content 
and  the  information  developed  during  the  analysis. 

A. 2.4  Key  Training  Products 

No  key  training  products  are  required  outputs  of  this  phase 
of  development.  However,  the  information  developed  during 
MAA  could,  and  should  support  training  task  analysis,  system 
employment  and  operation.  In  particular,  the  following 
areas  are  important  in  this  regard.  (1)  mission  area  tasks 
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MISSION  AREA  ANALYSIS 


MISSION  ELEMENT 
NEED  STATEMENT 


•  MISSION  AREA  TASKS 


/  •  OLD  THREAT  \ 
NEW  THREAT  \ 

•  A  VAI  LAB  LE /EXPLOITABLE > 
TECHNOLOGY 

•  PROJECTED  PERFOR-  J 
V  MANCE  MEASURES  / 


•  THREAT  OR  BASIS 
FOR  NEED 


•  EXISTING  AND  PLANNED 
CAPABILITIES  TO 
ACCOMPLISH  THIS 


OPERATIONAL  AND  X 
TECHNICAL  CON-  A 

STRAINTS 

•  RESOURCES  THE  ARMY 
IS  WILLING  TO  > 

x  commit  y 


•  MILESTONE  t 
DEVELOPMENT 
SCHEOULE 


•  RESOURCE  AND 
SCHEDULE  TO  MEET 
MILESTONE  I 
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and  subtasks,  and  task  performance  frequency  data;  (2) 
conditional  data  to  include  environmental  data,  e.g., 
terrain  and  weather  conditions,  threat  conditions,  the  types 
of  threats  or  targets,  and  the  densities  of  these  threats; 
(3)  anticipated  organizational  concepts  to  include  the 
organizational  echelons  and  the  responsibilities  of  these 
echelons;  (4)  the  anticipated  tactics  and  doctrine  for 
employing  the  weapon  system;  and  (5)  data  on  the  anticipated 
usage  rates  for  the  weapon  system. 

A. 2. 5  Current  Gaps  and  Limitations 

The  most  glaring  problem  surrounding  mission  area  analyses 
is  the  lack  of  a  systematic  set  of  procedures  for  conducting 
these  analyses.  TRADOC  is  currently  addressing  this 
problem.  Hopefully  the  new  TRADOC  procedures  will  include 
requirements  for  a  detailed  functional  analysis  of  a  new 
system  (to  be  completed  either  slightly  before  or  slightly 
after  MENS  development)  and  the  systematic  specifications  of 
the  system  functions  and  their  associated  goals  or 
objectives. 

The  availability  of  a  systematic  set  of  information  on 
mission  tasks,  subtasks,  and  system  functions  greatly 
facilitate  the  early  generation  of  individual  operator 
tasks,  collective  tasks  and  tactical  tasks  associated  with 
the  new  system.  The  specification  of  the  performance  goal 
is  extremely  valuable  as  it  lays  the  foundation  for  the 
construction  of  both  materiel  and  human  performance  goals. 
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A.  3  BIBLIOGRAPHY  OF  ARMY  DOCUMENTS 

Table  A-3  presents  a  bibliography  of  Army  Documents  related 
to  ETES. 


TABLE  A-3 


System  Acquisition 

DOD  Directive,  5000.1,  Major  System  Acquisition, 

_ ,  DOD  Directive,  5000.2,  Major  System  Acquisition, 

__  _  _ ,  AR  15-14,  System  Acquisition  Review  Council 

Procedures,  April  1978. 

AR  70-1,  Army  Research,  Development,  and  Acquisition, 
February  1977. 

_ ,  AR  70-10,  Test  And  Evaluation  During  Development  and 

Acquisition  Of  Material,  August  1975. 

. '  AR  70-15,  Product  Improvement  Of  Material,  June  1980. 

AR  70-17,  System/Prograin/Product  Management ,  November 

1976 


AR  70-27,  Outline  Development  Plan/Development  Plan/ 
Army  Program  Memorandum/Defense  Program  Memorandum/Decision 
Coordination  Paper,  March  1975. 

_ #  AR  71-3,  Force  Development  User  Testing,  March  1977. 
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AR  71-5,  Force  Development  Introduction  Of  New  Or 
Modified  Systems/Equipment ,  July  1969. 

_ ,  AR  71-9,  Force  Development  Material  Objectives  And 

Requirements ,  February  1975. 

_ ,  AR  1000-1,  Basic  Policies  For  System  Acquisition, 

April  1978. 

DA  Pam  11-25,  Life  Cycle  System  Management  Model  For 
Army  Systems,  May  1975. 


Integrated  Logistics  Support 


MIL-M-1 388-1 ,  Military  Standard  Logistics  Support 
Analysis,  October  1973. 

_ ,  DOD  DI-L-6138,  Integrated  Support  Plan  (ISP),  April 

1971. 


_  _  _ ,  DOD  DI-S-6171A,  Logistics  Support  Analysis  Record 

(LSAR)  Data,  February  1977. 

_ ,  AR  702-2,  Army  Material  Reliability,  Availability, 

And  Maintainability  (RAM),  December  1979. 

_ _ ,  AR  702-3,  Army  Material  Reliability,  Availability, 

And  Maintainability  (RAM),  November  1976. 

_  _  _ #  AR  750-1,  Army  Material  Maintenance  Concepts  And 

Policies,  March  1979. 
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,  TM  38-710,  Integrated  Logistic  Support  Implementation 
Guide  For  POD  Systems  And  Equipments,  March  1972. 

_ ,  TRADOC  Reg  700-1,  Integrated  Logistic  Support  (ILS), 

July  1977. 

DARCOM  TRADOC,  Material  Acquisition  Handbook,  January 

1980. 


_  ,  DARCOM-P  750-16,  DARCOM  Guide  To  Logistics  Support 

Analysis,  January  1979. 

__  _ ,  DARCOM-R  70-16,  Management  Of  Computer  Resources  In 

Battlefield  Automated  Systems,  July  1979. 

_  DARCOM  Primer,  ILS  Integrated  Logistic  Support. 


Manpower  Personnel  And  Training 


_ _ ,  MIL-M-63035  (TM),  Manuals,  Technical:  Front  End 

Analysis,  May  1977. 

_ ,  MIL-M-63036A  (TM),  Military  Specification  Manuals, 

Technical!  Operators,  Preparation  Of,  April  1980. 

_  _  _ ♦  MIL-M-63040  (TM),  Manuals,  Technical:  Extension 

Training  Materials  For  Integrated  Technical  Documentation 
And  Training  ( ITDT) ,  May  1977. 

_ MIL-STD-XYZ,  Task  Analysis:  Requirements  For  The  Use 

And  Application  Of  Task  Analysis  (Draft),  January  1980. 
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___,  Army  DI-H-1300,  Personnel  and  Training  Requirements, 
December  1969. 

_f  AR  108-2,  Army  Training  And  Audiovisual  Support,  July 
1976. 

_  350-1,  Army  Training,  May  1978. 

_ ,  AR  600-4,  Integrated  Personnel  Support  (IPS),  June 

1978. 


_ ,  AR  611-1,  Military  Occupational  Classification 

Structure  Development  And  Implementation,  April  1976. 

_  ,  TRADOC  Reg  71-12,  Total  System  Management-TRADOC 

System  Manager  (TSM) ,  September  1978. 

_  TRADOC  Hog  310-2,  Development,  Preparation,  And 

Management  Of  Training  And  Evaluation  Program  (ARTKP), 
December  1979. 

_ ,  TRADOC  Reg  351-4,  Job  &  Task  Analysis,  March  1979. 

_  ,  TRADOC  Reg  350-7  (Draft),  A  Systems  Approach  to 

Training. 


_  _  _ ,  TRADOC  Cir  70-1,  Training  Device  Development, 

February  1979. 

_  _  _ ,  TRADOC  Cir  350-2,  Officer  Job/Task  Analysis  And 

Training  Development,  March  1979. 
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TRADOC  Cir  350-3,  Individual/Collective  Training  And 
Development  Glossary,  December  1979. 

_  _ ,  TRADOC  Cir  351-1,  Common  Job  And  Task  Management, 

January  1980. 


__  _  _,  TRADOC  Cir  351-2,  Army  Correspondence  Coarse 

Program:  Subcourses,  June  1980. 
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APPENDIX  B 

EXAMPLE  OUTPUTS  FOR  FUNCTIONAL  REQUIREMENTS  AND 

DESIGN  CONCEPTS 


This  appendix  provides  examples  of  the  types  of  outputs 
associated  with  the  functional  requirements  and  design 
concept  areas.  These  outputs  are  only  designed  to 
demonstrate  the  basic  types  of  information  which  will  be 
required.  The  exact  format  of  the  outputs  cannot  be 

determined  until  specific  output  mechanisms  have  been 
identified. 
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TOP  LEVEL  FUNCTIONAL  REQUIREMENTS 


FIGURE  B-2  FUNCTIONAL  HIERARCHY  OPERATIONS 


TABLE  B-2  TERRAIN  IMPACTS  ON  FUNCTION 


TABLE  B-3  THREAT  IMPACTS  ON  FUNCTIONS 


TABLE  B-4  MISSION  PROFILE  IMPACTS  ON  FUNCTIONS 


FIGURE  B-4  GENERIC  EGUIPMCNT  HIERARCHICAL  STRUCTURE 


approved  oesign  concepts  ano  comparable  existing  equipment 


Function 

1.5  Fire  Control 
Computer 


TABLE  B-6  DESICN  ALTERNATIVES 


Alternative 

Company  A  Fire  Control  Computer  A 
Company  B  Fire  Control  Computer  B 


*Two  companies  have  submitted  proposals.  They  propose  essentially  the  same 
designs,  they  only  differ  in  the  fire  control  computer  they  propose  to  utilize. 


FIGURE  B-5 


EQUIPMENT  HIERARCHICAL  STRUCTURE  -  DESIGN  ALTERNATIVES 


Diagram  would  be  similar  to  Figure  £4,  only  with  specific 
equipment  replacing  generic  equipment . 
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FIGURE  B-6  INFORMATION  FLOW 


APPENDIX  C 

REVIEW  OF  PSYCHOLOGICAL  RESEARCH  RELATED 
TO  DESIGN 


This  Appendix  is  a  review  of  psychological  research  related 
to  the  construction  of  the  ETES  SDT.  It  is  divided  into 
three  sections.  The  first  section  reviews  the  role  of  the 
SDT  in  the  engineering  design  process  and  indicates  what 
general  areas  of  psychological  research  are  related  to  this 
role.  The  second  section  reviews  past  psychological 
research  relating  to  engineering  and  software  design  and  the 
implications  that  this  research  has  for  the  SDT.  The  third 
section  is  a  bibliography  of  the  psychological  research 
related  to  design. 

C.l  REVIEW  OF  DESIGN  PROCESS 


A  detailed  description  of  the  overall  weapon  system  design 
process  was  presented  in  Appendix  A  and  the  role  of  the  SDT 
was  detailed  in  Section  2.  Hence,  only  a  brief  review  is 
presented  here.  The  SDT  will  essentially  be  a  data  base 
management  system  for  describing,  storing,  updating,  and 
communicating  the  general  system  elements  listed  in  Table 
C-l.  (A  more  detailed  breakdown  of  these  general  elements 
is  presented  in  Section  2.)  The  SDT  will  have  the 
capability  of  describing  these  system  elements  for  several 
different  design  alternatives  and  for  describing  estimated 
elements  when  actual  data  is  not  available. 

Appendix  D  discusses  psychological  research  relating  to  the 
engineering  design  process — as  opposed  to  the  more  general 
weapon  system  design  process.  It  describes  research 
relating  to  the  more  general  weapon  system  development 
process  and  its  associated  information  flow  problems.  One 
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Table  C-l 

SYSTEM  ELEMENTS  CONTAINED  IN  SDT* 


General 

Elements 

Described 
by  SDT 

Description 
Required 
by  Design 
Alternative 

Description  Required 
for  Estimated 
as  well  as 

Actual  Data 

Functional  Requirements 

No 

No 

Design  Concepts 

Yes 

Yes 

Equipment-Task  Interface 

Yes 

Yes 

Tasks 

Yes 

Yes 

Skills  and  Knowledges 

Yes 

Yes 

Training  Program  Elements 

Yes 

Yes 

♦More  detailed  description  of  SDT  elements  is  presented  in  Section  2. 


can  distinguish  between  these  two  processes  by  noting  that 
the  engineering  design  process  refers  to  the  activities  of  a 
single  design  engineer  while  the  weapon  system  development 
process  refers  to  the  activities  of  a  large  number  of 
different  individuals  in  a  variety  of  different  technical 
disciplines.  Thus#  psychological  research  relating  to 
engineering  design  is  primarily  concerned  with  individual 
cognitive  processes  while  psychological  research  relating  to 
weapon  system  development  is  concerned  with  information  flow 
and  man-computer  interactions. 

C . 2  REVIEW  OF  PSYCHOLOGICAL  RESEARCH  RELATING  TO  THE 
ENGINEERING  DESIGN  PROCESS1 

Numerous  studies  (see  Thomas  and  Hankins,  1980#  and  Clemson 
University,  1979,  for  a  review)  have  shown  that  while  human 
resources  data  can  and  should  play  a  significant  role  in  the 
systems  design  process,  designers  do  not  always  utilize  the 
full  potential  of  the  data.  There  are  a  number  of  reasons 
for  this.  Certainly  it  is  partly  due  to  the  past  training 
and  experience  of  the  designer.  Another  reason  may  be  that 
human  resources  data  is  often  presented  in  a  form  that  is 
incompatible  with  the  cognitive  processes  the  designer 
employs  during  design.  One  important  consideration,  then, 
would  be  to  present  human  resources  data  in  a  form  that  is 
compatible  with  the  design  process  used  by  designers.  But 
to  do  this,  it  would  seem  appropriate  to  characterize  the 
design  process  itself  in  cognitive  terms.  This  section 
attempts  to  identify  the  cognitive  processes  underlying  the 


1  Section  C.2  was  prepared  by  Drs.  Paul  Ronco  and  Jack 
Hansen  under  a  subcontract  to  DRC.  They  are  now  part-time 
DRC  employees . 


engineering  design  process,  to  identify  and  classify 
potential  tools  and  aids  related  to  this  design  process,  and 
to  assess  the  applicability  of  these  aids  to  the  ETES  SDT. 
In  support  of  this  section,  an  annotated  bibliography  of  the 
major  references  in  this  area  has  also  been  developed.  This 
bibliography  is  contained  in  Section  C.3. 

C.2.1  The  Engineering  Design  Process 

Miller  (1969)  has  suggested  that  the  design  process  can  be 
broken  down  into  essentially  three  fundamental  underlying 
processes  —  namely,  goal  elaboration,  design  generation  and 
design  evaluation. 

1.  Goal  Elaboration  -  This  process  is  initiated  by  a 
statement  of  the  problem  and  an  examination  of  the 
goals.  It  involves  goal  decomposition  and  sub¬ 
goal  selection  until  sub-goals  are  specific  enough 
to  be  considered  as  functional  requirements.  The 
designer  may  or  may  not  be  involved  in  the 
specification  of  the  higher  level  goals.  Often 
the  designer  is  simply  presented  with  a  statement 
of  the  problem  and  the  operational  requirements  of 
the  system.  However,  whether  the  designer  is 
directly  involved  in  the  goal  elaboration  process 
or  not,  he  needs  to  be  supplied  with  goal-related 
information  including  the  following: 

•  systems  and  equipment  requirements  (e.g., 
equipment  must  be  portable.) 


functional  analyses 


applicable  constraints 


•  conclusions  drawn  from  previous  data  analyses 
and  inputs 

•  design  criteria,  specified  in  the  forms  of 
specifications  and  the  designer's  own 
accumulated  knowledge  and  experience.  (The 
latter  may  not  be  immediately  available  to 
the  designer  because  of  problems  associated 
with  information  retrieval  from  memory.  That 
is,  often  the  designer  possesses  relevant 
knowledge  which  is  not  spontaneously 
accessed.  However,  if  properly  cued,  recall 
and  recognition  of  this  data  is  possible.) 

In  analyzing  the  problem  and  establishing  sub¬ 
goals,  the  designer  will  require  certain  inputs. 
The  data  he  selects  for  input  will  depend  on  how 
he  construed  the  problem.  His  interpretation  of 
the  problem  will  in  turn  depend  on  his  own  past 
experience  with  similar  problems  as  well  as  any 
more  analytically  based  knowledge  he  may  possess. 

2.  Design  Generation  -  The  various  inputs  described 
above  contain  information  which  the  designer  will 
utilize  to  resolve  the  problem.  The  input, 
however,  is  different  from  the  information  it 
contains.  The  information  is  a  product  of  the 
designer's  interpretation  of  the  implications  and 
application  of  the  inputs  to  the  problem 
situation.  This  process  of  deriving  the  correct 
design  implications  from  an  input  is  the  most 
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difficult  part  of  the  design  process.  Some 
implications  are  relatively  obvious  (e.g.,  the 
need  for  portability)  whereas  others  can  be  quite 
obscure. 

Design  generation,  then,  starts  with  functional 
requirements  and  attempts  to  come  up  with  a  design 
organization  which  meets  the  functional  require¬ 
ments.  In  one  sense,  the  design  process  can  be 
thought  of  as  an  effort  to  organize  design 
elements  and  characteristics  into  a  whole.  It  is 
not  simply  a  treatment  of  isolated  parts,  even 
though  sub-problems  may  be  worked  on  in  isola¬ 
tion.  It  is  a  "holistic”  process.  This  is  a 
problem  in  and  of  itself.  The  design  elements  and 
characteristics  developed  in  the  achievement  of 
various  sub-goals  may  assume  different  values  as  a 
function  of  the  total  "Gestalt.”  Unfortunately, 
because  of  human  memory  limitations,  it  is  often 
difficult  for  the  designer  to  keep  track  of  all 
the  elements  that  enter  into  and  affect  the  design 
and  systems  operations,  and  he  thus  may  require 
some  assistance  in  keeping  track  of  the  elements 
and  relationships  in  the  particular  design 
problem. 

3.  Design  Evaluation  -  The  designer  must  be 

continuously  evaluating  how  well  a  proposed  design 
meets  the  stated  characteristics  and  requirements 
of  the  system.  An  important  feature  of  this 
process  is  that  it  may  uncover  new  requirements. 
The  whole  process  is  continuously  evolving.  New 
inputs  which  arrive,  usually  sequentially,  are 
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integrated,  analyzed  and  accepted  or  rejected. 
The  impact  is  continually  changing  as  a  function 
of  evaluation. 

'liven  this  description  of  the  engineering  design  process,  an 
attempt  was  made  to  identify  a  psychological  paradigm  which 
closely  paralleled  this  process  with  the  hope  that  this 
paradigm  would  provide  a  systematic  framework  for  organizing 
the  psychological  research  related  to  design.  Fortunately, 
several  past  investigators  of  the  design  process  (e.g., 
Miller,  1969;  Atwood,  et  al,  1979)  have  identified  such  a 
paradigm:  namely,  problem  solving  behavior.  Design  is 
obviously  (at  least  in  part)  a  form  of  problem  solving.^ 

In  the  subsection  which  follows,  the  problem  solving 
literature  relevant  ir-  the  design  process  is  reviewed. 

C.2.2  Problem  Solving  Behavior  and  Its  Implication  for 
Design 

Several  different  psychologists  have  come  up  with  schemes 
for  categorizing  the  different  phases  in  problem  solving 
behavior.  However,  two  of  these  schemes  are  especially 
relevant  to  the  engineering  process.  One  scheme,  developed 


2  It  must  be  emphasized  that  the  terms  design  and  “design 
process"  refer  to  the  process  that  an  individual  engineer 
might  go  through  in  developing  a  design.  They  do  not  refer 
to  the  more  general  acquisition  process  and  the  overall 
design  of  the  system  which  would  be  accomplished  by  a  large 
number  of  different  people.  However,  Appendix  D  does  deal 
with  research  related  to  this  more  general  process. 
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by  MilLer,  1969,  is  specifically  concerned  with  the  hardware 
design  process  and  is  closely  linked  to  the  "classical" 
psychological  literature  in  problem  solving.  The  second 
scheme  was  developed  by  Ramsey  and  Atwood,  1979,  to  describe 
the  software  design  process.  Actually  both  schemes  are 
compatible  with  one  another.  Table  C-2  displays  these  two 
schemes  and  indicates  how  they  can  be  directly  related  to 
one  another,  to  the  phases  of  the  design  process  described 
in  Section  C.2,  and  to  the  activities  in  the  weapon 
acquisition  process.  A  more  detailed  discussion  of  these 
two  schemes  is  provided  in  the  sections  which  follow. 

C.2. 2.1  Problem  Solving  and  Design:  Implications  from 
Classical  Problem  Solving  Research 

In  many  of  the  classical  discussions  of  problem  solving 
activity,  problem  solving  is  described  as  the  process  of 
finding  a  connection  between  the  known  and  the  unknown.  In 
other  words,  problem  solving  refers  to  the  process  of 
"generating"  a  connection  between  the  known  and  unknown. 
This  means  that  tasks  in  which  the  principal  activity 
involves  noticing  that  some  event  occur,!  or  is  present,  are 
recognition  tasks  and  not  problem  solving  tasks.  (See 
Wickelgren,  1979,  for  a  discussion  of  problem  solving 
behavior  and  its  relationship  to  other  cognitive  processes 
such  as  recognition.)  Utilizing  Miller's  (1969)  framework, 
the  problem  solving  process  can  be  broken  down  into  four 
basic  phases: 

1.  Problem  Definition  -  Any  problem  requires  the 
problem  solver  to  cognitively  represent  the 
information  in  some  way.  He  usually  utilizes 
auxiliary  memory  devices  that  range  from  paper  and 


C-8 


SCHEMES  FOR  DESCRIBING  PROBLEM  SOLVING  BEHAVIOR 
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pencil,  drawn  diagrams,  and  written  equations  to 
complex  computer  programs.  Satisfactory  problem 
solving  performance  requires  the  problem  solver  to 
develop  a  concept  of  the  problem  —  to  form  an 
appropriate  representation  of  the  problem.  There 
seems  to  be  unanimous  agreement  that  this  is  one 
of  the  crucial  steps  in  problem  solving.  "Problem 
representation"  refers  not  merely  to  formal 
notation  (syntactics)  but  encompasses  more 
specifically  the  designer's  perception  of  the 
logical  structure  of  the  problem.  This 

representation,  of  course,  includes  an 
understanding  of  the  goals  (see  Klein  and 
Weitzenfield,  1979,  or  a  review  of  procedures  for 
improving  goal  understanding).  If  the  goals  are 
not  clear,  it  is  difficult  (if  not  impossible)  for 
the  problem  solver  to  generate  procedures  that 
will  accomplish  the  goals.  Thus,  the  first  phase 
in  problem  solving  —  problem  definition  —  is 
extremely  critical. 

2.  Organization  -  The  first  element,  "Problem 
Definition,"  blends  imperceptibly  into  the  second 
element,  which  might  be  labeled  "Organization," 
the  construction  of  some  type  of  conceptual 
model.  Typically  in  design,  the  model  is 
constructed  on  the  basis  oi  analogy.  The  designer 
sees  the  current  problem  as  in  a  class  of  other 
problems  and  he  analyzes  the  problem  as  being 
similar  to  some  prior  problem.  The  prior 
instances,  the  analogous  ones,  serve  as  a  vehicle 
for  thought  and  the  construction  of  a  conceptual 
model.  For  example,  if  the  task  is  to  design  a 
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training  device  to  accomplish  a  given  training 
requirement,  the  first  step  typically  is  to  assess 
the  training  devices  previously  designed  to 
accomplish  the  same  or  similar  training 
requirements.  These  serve  as  analogies  and  provide 
a  variety  of  candidate  features  to  include  in  the 
new  device. 

3.  Function  Analysis  -  The  development  of  a 
conceptual  model  also  involves  the  analysis  of 
function.  This  involves  getting  an  idea  of  what 
kinds  of  things  must  happen  for  the  system  under 
design  to  operate  and  perform  its  function. 

4.  Invention  of  a  Mechanism  -  Finally,  the  designer 

must  get  an  idea  of  the  physical  structure  and 

operation  whereby  the  goals  and  mission  of  the 
system  can  be  accomplished.  As  mentioned 
previously,  he  often  gets  to  this  point  through 

the  use  of  analogical  reasoning. 

In  addition  to  the  multi-stage  approach  toward  describing 
the  problem  solving  process,  another  approach  to 

conceptualizing  the  design  process  has  been  to  describe 
problem-solving  behavior  in  terms  cf  an  "analytic/synthetic** 
dimension  (see  Ramsey  and  Atwood,  1979,  for  a  more  detailed 
description  of  this  dimension).  Under  the  analytic/ 
synthetic  conceptualization  the  design  process  is  viewed  as 
a  two-step  process,  in  which  the  individual  components  of 

the  problem  are  first  identified.  This  analysis  is  then 
followed  by  the  synthesis  of  a  solution.  The  main 
distinction  between  the  analytic/synthetic  and  the  multi¬ 
stage  conceptualizations  of  the  design  process  is  that 
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analytic/synthetic  approach  does  not  emphasize  the  explicit 
search  for  alternative  solutions.  Instead,  a  solution  is 
"synthesized"  based  upon  pattern  recognition  and  the  use  of 
components  from  past  solutions  to  other  problems. 

Analysis  usually  consists  of  decomposition  or  problem 
reduction.  The  overall  problem  is  decomposed  into 
subproblems  which  are  more  manageable  and  easier  to  solve. 
The  subproblems  consist  of  getting  from  givens  to  the 
subgoal  and  then  from  the  subgoal  to  the  goal.  If  one 

defines  subgoals  that  have  a  high  probability  of  being  on  a 
solution  path  in  the  problem  tree,  the  search  is  greatly 
reduced.  This  calls  for  intelligent  problem  solving  methods 
that  entail  trying  out  the  likelier  possibilities  first, 
even  if  such  heuristic  methods  do  not  always  work  (see  Klein 
and  Weitzenfeld,  1979).  This  is,  of  course,  what 

intelligent  human  or  computer  problem  solvers  do.  They 
guide  search  by  using  search  reduction  methods  which  prune 
large  problem  trees  in  clever  ways.  They  also  use 

representative  methods  which  code  or  recode  problems  so  as 
to  replace  large  problem  trees  with  small  ones  that  are 

nevertheless  equivalent  to  the  large  trees  with  respect  to 
solving  the  given  problem.  Problem  reduction  methods, 
however,  themselves  raise  problems  —  namely,  keeping  track 
of  the  various  goals  and  subgoals.  Keeping  track  of  active 
goals  appears  to  be  a  principal  source  of  information  load 
in  design.  The  human  problem  solver  has  fairly  severe 

cognitive  limitations  (especially  short  term  memory)  within 
which  to  operate.  When  a  problem  reduction  strategy  is  used 
on  a  highly  complex  problem,  it  is  very  likely  that  the 
problem  solver  will  have  difficulty  in  recalling  and 
utilizing  the  global  information  required  to  deal  with 
complex  subproblem  interdependencies.  Thus,  in  the  design 


012 


process  the  identification  of  points  involving  high  informa¬ 
tion  load  should  help  in  the  determination  of  appropriate 
automatic  aids  to  reduce  this  load  (see  Atwood,  et  al, 
1979). 

While  we  can  classify  the  problem  solving  or  reasoning 
processes  used  in  design  as  "analogical  reasoning"  or 
"analytic/synthetic,"  this  is  not  meant  to  imply  that  all 
designers  utilize  the  same  strategies  or  same  mode  of 
thinking.  There  are  individual  differences  between 

designers  as  to  the  mode  of  cognitive  activity  they  use.  For 
example,  Greeno  (1973)  makes  a  distinction  between  formal 
and  informal  reasoning.  Formal  reasoning  involves  the  use 
of  syntactic  information,  formal  languages  and  relatively 
mechanical  procedures.  Informal  reasoning  involves  semantic 
models.  The  reasoning  processes  differ  considerably  between 
these  two  classes.  Larkin  presents  data  which  suggest  that 
very  experienced  physicists  may  adopt  predominantly  semantic 
(intuitive)  approaches  to  the  solution  of  physics 
problems.  Relatively  inexperienced  physics  students,  on  the 
other  hand,  tend  to  proceed  immediately  to  the  use  and 
solution  of  mathematical  equations  and  thus  employ  formal 
reasoning.  Presumably,  approaching  the  problem  with 

informal  reasoning  would  allow  the  problem  solver  to  make 
much  greater  use  of  his  knowledge  of  the  problem  domain  and 
experience  with  conceptually  related  problems.  It  is 
possible  that  the  very  formal  syntactic  approach  may  well 
deprive  the  designer  of  the  ability  to  use  problem  relevant 
knowledge  to  resolve  difficulties  which  arise  in  design. 
Thus,  algorithmic  strategies  may  limit  the  advantageous  use 
of  relevant  knowledge  by  experienced  designers.  On  the 
other  hand,  they  may  be  quite  advantageous  if  used  by 
inexperienced  designers  for  appropriate  problems. 
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Implications  for  SDT 


• 

Given  the  above  descriptions  of  the  design  process  described 
above,  it  is  possible  to  identify  some  general  human 
limitations  which  have  direct  impact  on  the  ETES  SDT.  Table 
C-3  shows  some  of  the  major  human  limitations  surrounding 
problem  solving  behavior  and  the  general  requirements  they 
generate  for  the  SDT. 

C.2.2.2  Problem  Solving  and  Design:  Implications  from 
Software  Design  Research 

Recently  there  has  been  a  good  deal  of  research  on  the 
psychological  processes  underlying  the  software  design 
process.  Because  the  ETES  SDT  will  essentially  be  a  data 
base  management  system,  an  attempt  was  made  to 
systematically  review  the  literature  in  this  area. 
Fortunately,  a  comprehensive  review  of  the  literature  in 
this  area  has  been  completed  by  Ramsey  and  Atwood  (1978). 
The  details  of  this  review  are  not  repeated  here.  Section 
C.3  summarizes  the  problem  solving  stages  that  were 
identified  by  Atwood  and  Ramsey  and  their  comments  on  the 
major  human  limitations  surrounding  each  stage. 

•  Implications  for  ETES 

In  addition  to  identifying  relevant  stages  in  the  design 
process  and  some  of  the  major  limitations  of  each  stage, 
Atwood  and  Ramsey  also  identified  some  aiding  mechanisms 
which  could  be  used  to  overcome  these  limitations.  Table  C- 
4  displays  these  mechanisms  and  the  implications  these 
mechanisms  have  for  the  SDT. 
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Table  C-3 

HUMAN  LIMITATIONS  RELATED  TO  ETES 
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Table  C-4  PROBLEM-SOLVING  AIDS  RELATED  TO  ETES* 


Aiding 

Mtehenum 

Oaicription 

Commontt 

Principal 

Reference! 

Implication! 
for  SDT 

Altarnativa 

Evaluation 

ThtM  aidt  may  either  automat* 
th*  uaar't  a  valuation  criteria,  require 
tha  umt  to  uia  aitabiiihad  criteria, 
or  aimulata  tha  raaulti  of  actioni 
that  do  not  have  wail  attablithad 
•valuation  criteria. 

Except  for  aidt  that  automata  tha 
utar’t  evaluation  critaria.  thaaa  talk 
aidt  art  tatk-tpadfic.  Mott  utaful  if 
tha  tatk  it  not  wail-dafinad  or  if  a 
large  number  of  evaluation  criteria 
need  ba  contidarad. 

Brown  at  al  (197S) 
Hermann  (1M7) 

Rapp  (1972) 

Smith,  H.  T.  and 
Crabtree  (1975) 

SDT  muR  ba  able 
to  faad  into  theta 
altarnativa  evaluation 
aidt. 

Altarnativa 

Ganaration 

Thaaa  aidi  ara  primarily  uiad  to 
genarata  altarnativaa  that  tha  uaar 
would  not  normally  conudar  or, 
for  aatramaly  walMafinad  taaki, 
to  praMnt  algorithmically 
datarminad  alternative!. 

Except  for  well-defined  tatk  domamt, 
where  they  may  have  vary  little 
impact,  they  arc  difficult  to 
conitruct.  Can  ba  coat-affoctiva  for 
training  application*,  but  generally 
ara  of  limited  ute  in  complex 
probtem-aolving  tatkt. 

Baldwin  ft  Sikiotty 
(1977) 

Gagliardi  at  al 
(1966) 

SOT  mutt  genarata 
data  beta  information 
option*  for  utar 
whenever  it  it  pouibta 
to  do  to.  However,  SOT 
will  not  ba  directly 
involved  in  generating 
detign  option*. 

Automatic  Action 
Execution 

Such  aidi  permit  tha  uaar  to  name 
tha  d  cured  action  without 
aaplicitly  carrying  out  tha  Itapa 
involved  in  itt  execution. 

Mott  utaful  whan  tha  retultt  of 
applying  an  action  do  not  impact 
wbtaquant  problam-tolving  actioni. 

If  thit  it  the  cmc,  tha  utar  may 
naad  tophiaticatad  alternative 
evaluation  hauriattca. 

Carlton  It  Hodgton 
(1977) 

Harm  ft  Gabbard 
(1986V 

Puifar  (1971) 

SOT  mutt  ba  powerful 
anough  to  allow  for 
automatic  action 
•xccutiont  of 
information  ttoraga  and 
retrieval  command*. 

Automatic 

Takeover 

This  type  of  aid  function*  a«  an 
automat  ad  dadtion  maker  that  it 
able  to  teiact  altarnativa  actioni  on 
the  bawi  of  prior  obaarvatiom  of  th* 
human  daciwon  makar't  behavior. 
Although  allocation  of  control  to 
thii  aid  ocouri  automatiaaHy.  whan- 
•var  10 ma  criterion  of  corraapon- 
danoa  between  predicted  and  obaarvad 
human  behavior  u  raaahad.  voluntary 
turnover  of  control  it  alto  poiwbie. 

Although  damonitratad  to  ha 
affective  in  tome  context!  (a.g.. 
oontrol  tatkt),  tha  range  of  tatkt 
m  which  thit  it  appropriata  it  not 
wad  under rtood.  Utar  aceaptanoa 
may  ba  low  and  thou  Id  ba 
carefully  examined 

Fraady  at  al  (1972) 
Staab  &  Fraady 
(1978) 

SOT  mutt  ba  capable 
of  generating  automatic 
"haip”  quartet  whan 
utar  makti  maior  error*. 

Backtracking 

Such  an  aid  aliowi  the  problem 
aoivor  to  "undo"  tha  afftata  of 
raeant  actiont  and  return  to  an 
earlier  state  of  tha  problem- toiving 
prooaai  without  actually  ttarting 

Oyff, 

Utaful  in  taaki  whara  it  it 
potalbia  to  "undo"  recant  action*. 

Can  improve  parformenaa  at 
relatively  littte  development  aott 

Carlton  ft  Hodgton 
(1977) 

Michie  at  cl 

(19BB) 

Tcitalman  (1972) 

SOT  muR  have  capability 
of  providing  teparete 
work  tpeeet  for  each 

uaar. 

•attar  Weighting 
of  Unraliobla 

Data 

Thi*  aid  re-cod*i  low-fidaiitv  data 
into  a  form  that  n  more  readily 
uiabi*  by  the  problem  toivar. 

Oapanda  on  tha  ability  to 
araurataty  raaodl  iow-fidality  data. 

Topm.llar  (IMS) 
Mowall  ft  Gattyt 
(19M) 

SOT  mu  it  dearly 
diRingunh  between 
animated  and  actual 

data. 

Chanf*  of 

Problem 

Rapraaantatlon 

Typical  impiamanwtiowi  of  thit 
aid  prnont  problem*  aa  laomorphia 
variatfom  of  more  itandtrd  problem 
rapretentatmm.  It  it  intended  that 
this  will  aid  tha  problem  toivar  in 
taivetmg  an  appropriata  and 
efficient  problam  formulation. 

Mor  utaful  in  wail -under  Rood 
tatkt.  An  inappropriate 
raptteeiwttioo  may  tanoutly 
dagmda  parformenaa. 

Chatiar  ft  Turn 
(19B7) 

Smith,  H.  T  (1974) 
Nawtlad  ft  Wynne 
(1978) 

SOT  muR  ba  capable 
of  acoaaaing  aoiaclad 
tete  of  information 
by  a  variety  of 
different  meant. 

Connatanev 

Improvement 

Thu  type  of  aid  atanti  tha  uteri 
applying  thaw  own  daemon 
lirmpn  conamantly  in  caaaa  m 
wfuch  that*  tvatagioc  art 

complex. 

Utaful  for  aapert  problam  mlvart 
«  walhdaflnad  tatkt.  Including 
wHiatant  vanotMitv  tu  adapt  to 
individual  utar*  may  ba  difficult. 

Oavit  at  al  11975) 
Fraady  at  al  1 1970 

SOT  mu  it  have 
•vRematK  procedural 
for  "walking"  tha  utar 
through  itt  uo. 

Daemon  Strategy 
Improvement 

Such  aidt  atain  tha  uaar  m 
applying  probiem-tolving 
techmquat  that  would  not 
normally  be  aoncidered  or 
known. 

Utaful  m  wad -defined  tatkt  in 
wtudi  optimal,  or  near  optimal, 

tra  iakAMMI 

(fVrtvwfWfi  fri  angRti, 

or  in  tatkt  m  which  general 
heuriftiae,  tuch  at  probltm 
reduction  ara  epphaable.  Require* 
da  an  tad  knowledge  of  tha  talk. 

Caruao  (19701 

Gagliardi  at  al 

(19BBI 

Huger*  at  at  (19B4I 
Woide  (1988) 

Not  tpplicabia  to  SOT 

Dacompoution  and 
Rtoompoaition 

Thit  typo  of  aid  allowt  tha  uaar  to 
divide  the  original  problam  into  tub 
problem*.  The  tohrtmna  of  tha 
variout  tubprabiamt  ara  than 
combmad  mto  a  tofution  to  the 
original,  larger  problem. 

Utaful  only  if  t  tatk  aan  ba 

tubprabiamt.  Require*  a  good 
uodotRondmg  of  the  tatk. 

Krolak  (1871) 

SOT  muR  have  budt  in 
tuorarehieal  ttructwa 
for  data  itamt  within 
talactad  filet  to  permit 
daoompotition  and 

raoompowtwn. 

Oitruptmn  of 

*  1  wW 

Sueh  an  aid  it  intended  to  durupt 
any  btaa  or  "tatT  that  tha  wtar 

Potentially  utaful.  but  may 
durupt  an  appropriate  “tat." 

Stawan  (1878) 

Not  applicable  n  SOT 

*Ti tta  d— id—  tftm  Hwwty  an*  Am— od. 
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C . 3  BIBLIOGRAPHY  OF  PSYCHOLOGICAL  RESEARCH  RELATED  TO 
DESIGN 

Tables  C-5  and  C-6  are  tables  taken  from  a  report  on  human 
factors  in  computer  systems  by  Ramsey  and  Atwood.  The 
listed  references  can  be  found  in  a  separately  published 
annotated  bibliography  (Ramsey,  Atwood  &  Kirschbaum, 
1978).  References  marked  with  a  single  asterisk  indicate 
reports  of  surveys,  questionnaires  or  summarized  data.  A 
double  asterisk  indicates  a  report  of  performance  data  or 
detailed  results  of  experimental  studies.  It  should  be  kept 
in  mind  that  the  references  are,  for  the  most  part, 
concerned  with  problem  solving  behavior  as  it  relates  to 
software  design. 


Subtask 
or  Phase 

Problem 

Recognition 


Problem 

Definition 


Table 

Basic  Subtasks  or  Phases 


^nvolv 


ed  in  Problem  Solving 


Description 


Comments 


Principal 

References 


The  first  stage  in  prob¬ 
lem  solving  is  to  recog¬ 
nize  that  a  problem 
exists.  People  are 
frequently  slow  to 
recognize,  or  at  least 
react  to,  problems. 

This  is  especially  true 
in  situations  in  which  a 
person  must  monitor  the 
current  state  of  the  en¬ 
vironment  and  detect  or 
react  to  critical 
changes . 


.iA  primary  need  is  for 
;an  aid  that  alerts  the 
•problem  solver  to 
"relevant”  changes  in 
the  environment.  The 
[relevant  variables  for 
ja  given  task  can  be 
{difficult  to  define. 
'Current  status  displays, 
historical  displays,  and 
aids  for  dealing  with 
degraded  data  can  be 
useful.  If  the  relevant 
variables  are  identified 
coding  techniques  can  be 
very  useful. 


Booth  et  al 
(1968) 
Chesler  4 
Turn  (1967) 
Scanlan  (1975) 
Smith,  R.L.  et 
al  (1972) 
Topmiller  (196 
:  Wylie  et  al 
(1975) 


t  ! 

I 


After  a  problem  is  re¬ 
cognized,  the  problem 
solver  must  determine 
how  to  formulate,  or 
represent,  the  problem. 
In  most  cases,  there 
are  several  alternative 
formulations  for  a 
given  problem.  The 
overall  success  of  prob¬ 
lem  solving  strongly 
depends  on  selecting  an 
appropriate  formulation. 


Aids  that  provide  a 
change  in  problem  repre¬ 
sentation  (e.g.,  graphi¬ 
cal  displays,  isomorphic 
representation)  can  be 
extremely  useful.  De¬ 
veloping  alternative  re¬ 
presentations  requires  a 
thorough  understanding  of 
the  specific  problem  and 
the  problem-solving  pro¬ 
cesses  that  are  most 
appropriate.  Allowing 
the  problem  solver  to  de¬ 
compose  the  problem  into  * 
subtasks  and  recombine 
these  subtasks  in  various 
ways  can  be  useful  in  ■ 
problems  with  relatively 
independent  tasks.  This  ! 
type  of  aid  is  less  diffi¬ 
cult  to  develop  than 
changes  in  problem  repre-  j 
sentation,  but  it  is  also  ! 
less  general.  i 


Balzer  k  Shire 
(1968) 

Cushman  (1972) 
Krolak  et  al 
(1971) 

Newsted  k  Wynn 
(1976)* 
Smith,  H.T. 
(1974)* 

Stewart  (1974) 


Subtask 
or  Phase 


Description 


Comments 


Principal 
[References 

Goal  In  some  cases,  the  goal  The  primary  difficulty  None 

Definition  ; to  be  achieved  is  pre-  .is  that  a  selected  goal 
defined.  In  other  cases  may  not  be  attainable. 

‘ (e.g.,  tactical  planning),  It  may  be  useful  to  aid 
■the  problem  solver  must  the  problem  solver  in 
:  select  an  appropriate  generating  several  alter-  , 
goal.  A  selected  goal  native,  logically  con-  j 
:must  be  not  only  appro-  sistent  goal  structures 
priate,  but  also  and  to  delay  selecting  a  { 

attainable.  ^specific  goal  until  later  j 

in  the  problem-solving  \ 

process.  Research  on  j 

goal  definition  is  j 

•  ‘lacking.  I 

t 

J  1 

Strategy  Strategy  selection  is  The  majority  of  strategy-  .Bennett  (1971) 

Selection  is  concerned  with  selection  aids  are  con-  Caruso  (1970)* 

determining  the  general  jcerned  with  specific  Wilde  (1969)* 

j approach  that  will  be  jproblem  domains.  This  is  i 
'used  in  problem  solving,  (appropriate  since  strategy 
! In  some  cases,  a  certain  {selection  is  strongly  ‘ 
strategy  is  dictated  by  .driven  by  experience  in  a  J 
the  problem  represents-  ; given  domain.  In  domains  ; 

, tion  that  is  selected.  ;in  which  problems  can  be  J 
In  general,  strategy  j decomposed  into  fairly 

selection  is  based  on  | independent  subproblems,  j 
previous  experience  with  :aids  that  allow  the  user 
•a  given  class  of  related  ,to  select  strategies  for 
problems.  .these  subproblems  inde- 

,  . pendently  before  combining 

: them  into  an  overall 

{  strategy  can  be  very  use-  : 

■ ful .  Additional  research 

J  is  needed  on  the  nature  of 

j  specific  problem-solving  j 

‘  ' tasks  and  the  strategy  ; 

!  selection  heuristics  used  j 

!  by  expert  problem  solvers .1 

!  This  would  enable  the 

(  construction  of  techni-  I 

•  qua s  to  aid  the  less  ex-  i 

perienced  user  in  this  i 

;  phase  of  problem  solving.  I 

i 

i 

4 
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Subtask 
or  Phase 

Alternative 

Generation 


Alternative 

Evaluation 


Description 

In  well-defined  tasks, 
the  problem  solver  can 
usually  generate  all 
alternative  actions  that 
may  be  appropriate.  If 
there  is  a  large  number 
of  alternatives,  however, 
the  problem  solver  may 
not  be  able  to  retain  all 
alternatives  in  memory 
for  later  evaluation.  If 
the  task  is  not  well- 
defined,  the  problem 
solver  may  not  be  able  toj 
generate  appropriate 
alternative  actions. 


Comments 


IPrincipal 

•References 


.•Brown  et  al 
?  (1974) 

iCarlson  k 
j  Hodgson 
I  (1977)* 
•Gagliardi  et  a! 
i  (1965)* 
iHormann  (1967) 


Problem  solvers  are  gen¬ 
erally  very  good  at 
evaluating  alternatives 
in  a  manner  consistent 
with  their  perception 
of  the  problem  and  the 
goal  to  be  achieved. 

If  the  alternatives 
have  far-reaching  con¬ 
sequences  or  if  they 
must  be  evaluated  with 
respect  to  a  large 
number  of  factors,  the 
problem  solver* s  memory 
and  processing  limita¬ 
tions  may  be  exceeded. 


Aids  that  store  a  large 
number  of  user-generated 
alternatives  can  easily 
be  developed  and  can  also 
be  effective.  The 
principal  need  is  for 
aids  to  suggest  alterna¬ 
tives  that  the  user  is 
unable  to  generate.  Such 
aids  have  been  developed 
for  training  applications 
and  for  cases  in  which  j 
the  computer  has  been  pro¬ 
grammed  to  generate  opti-  I 
mal  solutions  without 
explicit  user  interaction.' 
For  ill-defined  task  en-  j 
vironments,  aids  that 
suggest  hypotheses  to  be 
tested  may  aid  in  alterna 
tive  generation.  Although 
potentially  very  useful, 
such  aids  could  be  diffi¬ 
cult  to  construct. 


In  extremely  well-defined  ‘Balzer  k  Shire; 


task  environments,  aids 
have  been  developed  that 
allow  the  user  to  simu¬ 
late  the  consequences  of 
various  alternatives. 

Although  they  are  very 
useful  in  specific  cases,  ?reedy  et  al 
such  aids  have  limited  '  (1976)** 

generality.  Aids  that  Richie  et  al 
capture  the  user* 3  evalu- 


!  (I960) 

•Brown  et  al 
I  (1975) 

'Davis  et  al 
:  (1975)** 

Doutriaux  (197' 


(I960) 


#* 


Crabtree 
(1975)** 
Yntema  k  Clem 
(1965)* 


ation  heuristics  and  then  'Rapp  (1972)* 
filter  information  to  be  Smith, ~H.T.  k 
consistent  with  these 
heuristics  and  sometimes 
even  present  alternatives 
considered  to  be  optimal 
are  especially  useful  whenj 
a  large  number  of  evalua¬ 
tion  heuristics  must  be 
applied.  This  type  of 
aid  is  both  effective  and 
general,  but  it  requires 
a  great  deal  of  effort  to  ! 
implement . 
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Subtask  | 

or  Phase  Description  i  Comments 

i 

t 

Alternative  The  last  phase  of  prob-  Automatic  execution  of 

Selection  &  lem  solving  is  con-  user-specified  actions 

Execution  cerned  with  implementing  can  aid  the  user  in 
the  solution.  interacting  with  the 

problem-solving  environ¬ 
ment.  Aids  that  auto¬ 
matically  take  over  the 
problem-solving  process 
may  also  be  useful ,  but 
they  should  be  used  with 
caution. 


!  Principal 
!  References 


Bursky  et  al 
(1968) 

Freedy  et  a" 
(1976)** 
Hanes  &  Gebha) 
(1976)* 
Pulfer  (1971) 
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Table  c-6 

Types  of  Problem-Solving  Aids 


Aiding 

Mechanism 

Alternative 

Evaluation 


Alternative 

Generation 


Automatic 

Action 

Execution 


Automatic 

Takeover 


DescriDtion 


These  aids  may  either 
automate  the  user's 
evaluation  criteria# 
require  the  user  to  use 
established  criteria,  or 
simulate  the  results  of 
actions  that  do  not  have 
well  established  evalua¬ 
tion  criteria. 


These  aids  are  primarily 
used  to  generate  alter¬ 
natives  that  the  user 
would  not  normally  con¬ 
sider  or,  for  extremely 
well-defined  tasks,  to 
present  algorithmically 
determined  alternatives. 

i 

i 


I  Comments  j 

i  - 

J  Except  for  aids  that 
automate  the  user's 
evaluation  criteria, 
these  task  aids  are  task- 
specific.  Most  useful  ! 

if  the  task  is  not  well-  » 

|  defined  or  if  a  large  j 

! number  of  evaluation  ! 

criteria  need  he  con-  ) 

sidered.  { 


Principal 

References 


Brown  et  al 
(1975) 

Hormann  (1967) 
Rapp  (1972)* 
Smith,  H.T.  k 
Crabtree 
(1975)** 


♦ 


Except  for  well-defined 
task  domains,  where  they 
may  have  very  little  im¬ 
pact,  they  are  difficult 
to  construct.  Can  be 
cost-effective  for  train¬ 
ing  applications,  but 
generally  are  of  limited 
use  in  complex  problem¬ 
solving  tasks. 


Baldwin  k 
Siklossy 
(1977) 

Gagliardi  et  al 
(1965)** 


isuch  aids  permit  the  user ‘.Most  useful  when  the  re-  ;  Carlson  k 
to  name  the  desired  suits  of  applying  an  !  Hodgson  (197" 

action  without  explicitly j action  do  not  impact  sub- [Hanes  k  Gebharc 
carrying  out  the  steps  [sequent  problem-solving  ;  (1966)* 

involved  in  its  execution! actions .  If  this  is  the  :Pulfer  (1971) 

lease,  the  user  may  need  j 
i sophisticated  alternative: 

[evaluation  heuristics.  j 


This  type  of  aid  func¬ 
tions  as  an  automated 
decision  maker  that  is 
able  to  select  alterna¬ 
tive  actions  on  the 
basis  of  prior  observa¬ 
tions  of  the  human 
decision  maker's  be¬ 
havior.  Although 
allocation  of  control  io 
this  aid  occurs  automati¬ 
cally  whenever  some 
criterion  of  correspon¬ 
dence  between  predicted 
and  observed  human 
behavior  is  reached, 
voluntary  turnover  of  con¬ 
trol  is  also  possible. 


i 

Although  demonstrated  to  *Freedy  et  al 


be  effective  in  some  con-  , 
[texts  (e.g.f  control  j 

[tasks),  the  range  of  , 
♦tasks  in  which  this  is 
(appropriate  is  not  well  1 
[understood.  User  accept-  ; 
ance  may  be  low  anc;  should 
be  carefully  examined. 


(1972) 

Steeb  &  r reedy 
(1976)* 


c-:  * 


Aiding 
Kechani sm 

Back¬ 

tracking 


Better 
Weighting 
of  Unreli¬ 
able  Date 


Change  of 
Problem 
Representa¬ 
tion 


Decision 

Consistency 

Improvement 


Decision 

Strategy 

Improvement 


j  Description 

i 

Such  an  aid  allows  the 
problem  solver  to  ’’undo" 
the  effects  of  recent 
!  actions  and  return  to  an 
earlier  state  of  the 
problem-solving  process 
without  actually  starting 
over. 


This  aid  re-codes  low- 
fidelity  data  into  a 
form  that  j  s  more 
readily  useable  by  the 
problem  solver. 


Typical  implementations 
of  this  aid  present 
problems  as  isomorphic 
variations  of  more 
standard  problem  repre¬ 
sentations.  It  is 
intended  that  this  will 
aid  the  problem  solver 
in  selecting  an  appropri¬ 
ate  and  efficient  problem 
formulation. 


This  type  of  aid  assists 
the  users  applying  their 
own  decision  strategies 
consistently  in  cases  in 
which  these  strategies 
are  complex. 


Comments 

Useful  in  tasks  where  it 
is  possible  to  "undo" 
recent  actions.  Can 
improve  performance  at 
relatively  little 
development  cost. 


Depends  on  the  ability 
to  accurately  recode  low- 
fidelity  data. 


Most  useful  in  well- 
understood  tasks.  An 
inappropriate  representa¬ 
tion  may  seriously 
degrade  performance. 


Useful  for  expert  problem 
solvers  in  well-defined 
tasks.  Including  suffi¬ 
cient  versatility  to 
adapt  to  individual  users 
may  be  difficult. 


Such  aids  the  user 

in  applying  problem¬ 
solving  techniques  that 
would  not  normally  be 
i  considered  or  known. 


I’seful  in  well-defined 
tasks  in  which  optimal ,or 
near  optimal,  problem¬ 
solving  techniques  are 
known,  or  in  tasks  in 
which  general  heuristics, 
such  as  problem  reduction 
are  applicable.  Requires 
detailed  knowledge  of  the 
task. 


(Principal 

(References 

iCarlson  k 

Hodgson  (1977 
Mi chi  e  et  al 
(1968)* 

Teitelman  0  97^ 


Topmiller 
(1968)** 
Howell  k  Gettys 
(1968)* 


Chesler  k  Turn 
(1967) 

Smith,  H.T. 

(1974)** 
Newsted  k  Wynne 
(1976)* 


Davis  et  al 
(1975)** 
Freedy  et  al 
(1976)** 


Caruso  (1970)* 
Gagliardi  et  al 
(1965)** 
Rogers  et  al 
(1964) 

Wilde  (1969)* 
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Aiding 

Mechanism 

Decomposi¬ 
tion  and 
Recomposi¬ 
tion 


Disruption 
of  Psycholo 
gical  Set 


Jr.  tended 
Memory 


Lockout 


Rapid 

Trial-and- 

Error 


Description 

This  type  of  aid  allows 
'  the  user  to  divide  the 
; original  problem  into 
subproblems.  The  solu¬ 
tions  of  the  various 
subproblems  are  then 
combined  into  a  solution 
to  the  original,  larger 
problem. 


Such  an  aid  is  intended 
to  disrupt  any  bias  or 
" sets”  that  the  user  may 
employ  and,  thereby 
stimulate  more  creative 
or  novel  problem-solving 
attempts. 


I  This  aid  allows  the  user 
to  store  and  retrieve 
problem-relevant  informa¬ 
tion.  This  information 
may  initially  be  genera¬ 
ted  by  the  ujer  or  by 
other  problem-solving 
aids,  such  as  aids  for 
alternative  generation 
and  evaluation. 


!  Comments 

juseful  only  if  a  task 
;can  be  decomposed  into 
jindependent  subproblems. 
iRequires  a  good  under¬ 
standing  of  the  task. 


'Principal 

•IReferences 

Ijirolak  (1971)* 


Potentially  useful,  but 
may  disrupt  an 
lappropriate  “set M . 


Very  useful  in  almost  all 
itasks.  Success  is 
related  to  the  ease  of 
retrieval  from  external 
memory. 


In  an  interactive  problem-^  Although  demonstrated 


solving  situation,  this 
technique  restricts  the 
problem  solver' 3  access 
to  the  computer  for  some 
period  of  time  after  the 
!  presentation  of  the 
•  results  from  the  current 
j  request  for  information. 


| This  aid  allows  the  user 
j to  rapidly  and  easily 
I  examine  the  consequences 
(of  alternative  action  by 
j simulating  their  appli- 
5  cation. 


^effective  in  some  context 
(user  acceptance  was  low. 
jThe  tradeoff  between  user 
[performance  and  user 
|acccptance  should  be  care-j 
fully  considered. 


.•Easily  implemented  in  wel}| 
(defined  tasks.  May  off¬ 
set  inadequacies  in 
^decision  strategy 
improvement  aids. 


Stewart  (1976) 


Balzer  k  Shire? 
(1968) 

Newsted  k  Wynne 
(1976)* 

Smith,  H.T.  k 
Crabtree 
Q975)** 


Boehm  et  al 
(1971)** 
Seven  et  el 
(1971)** 


Belzer  k  Shire 
(1968) 

Carlson  k 

Hodgson  (197" 
Rapp  (1972)* 
(Wilde  (1969)* 


c-:s 


Aiding 

i 

! 

1 

1 

| 

Mechani sm 

Description 

Comments  1 

Strategy 

These  aids  attempt  to 

A  prerequisite  for 

Capture 

model  and  predict  the 
u*serTs  behavior. 

Strategy  capture  is 
generally  used  in  con¬ 
junction  with  other  aids, 
such  as  automatic  take¬ 
over  or  alternative 
evaluation. 

developing  automatic 
takeover  aids.  Best 
suited  to  tasks  that 
allow  algorithmic, 
rather  than  heuristic, 
strategies. 

Principal 

References 


Doutriaux 


(1973)* 

Freedy  et  al 
(1976)** 
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BIBLIOGRAPHY  &  REFERENCES 


The  items  listed  in  Part  I  are  those  that  were  used  as 
specific  and  general  references  for  the  main  report.  Those 
listed  in  Part  II  are  the  ones  cited  in  rabies  C-d  and  C-o 
in  the  Appendix  of  the  main  report.  Annotations  for  these 
can  be  found  in  the  report,  "Annotated  bibliography  on  human 
factors  in  software  development"  by  Atwood  et  al. 
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1.  Amkreutz,  J.H.A.E.  Cybernetic  model  of  the  design  process. 

Computer  Aided  Design/  1976  ,  8  (3),  187-.1  92  . 

Computer  aided  design  can  be  seen  as  a  process  in 
which  a  careful  integration  of  the  specific  characteristics  of 
man  and  machine  is  taking  place.  This  integration  may  lead 
to  better  design  results,  quantitatively  ana/ui  gual  JLLaLjtv'Cij;  . 
The  realization  of  this  integration  in  CAD  systems 
necessitates  a  renewed  and  profound  analysis  of  the  design 
process.  A  model  of  the  design  process  is  developed  against 
the  background  of  the  evolution  of  ch is  process.  To  this 
end,  cybernetics  is  used  as  a  meta-language.  The  development 
of  CAD  systems  based  on  this  model  is  discussed. 


2.  Askren,  W.B.  Human  resources  as  engineering  design  criteria. 
AFHRL-TR-76-1 ,  Brooks  AFB ,  Texas:  AF  Human  Resources 
Laboratory,  March  1976. 

Summarizes  the  results  of  a  number  of  studies  which 
have  been  performed  in  an  attempt  to  develop  a  technology 
for  using  human  resources  data  as  criteria  in  engineering 
design  studies.  Eight  investigations  conducted  during  the 
period  1966-1975  are  briefly  described.  The  results  of  the 
eight  studies  are  integrated  around  the  six  topics  of: 
feasibility  and  practicality  of  using  human  resources  data  as 
criteria  in  engineering  design,  methods  for  using  the  data  in 
design  studies,  effect  on  the  system  of  using  the  data  as 
design  criteria,  types  of  human  resources  data  most  relevant 
for  use  as  design  criteria,  methods  for  generating  human 
resources  data  for  use  in  design  studies,  and  nature  of  the 
engineering  design  process. 


3.  Atwood,  M.E.  et  al*  Annotated  bibliography  on  human  factors 
in  software  development.  All  Tech  Rep  P-79-1.  Englewood, 
Colorado:  Science  Applications,  Inc.,  June  1979. 

As  part  of  a  larger  Army  Research  Institute  effort  to 
survey,  synthesize,  and  evaluate  the  state  of  the  art  in  the 
area  of  human  factors  as  applied  to  software  development,  a 
fairly  extensive  literature  survey  was  conducted.  This 
resulting  bibliography  contains  citations  of  479  articles  or 
xeports  pertaining  to  the  behavioral  aspects  of  software 
design,  programming,  coding,  debugging,  testing,  evaluation, 
and  maintenance.  Most  citations  are  accompanied  by  descriptive 
abstracts,  and  all  are  indexed  by  author,  publication  source, 
institutional  affiliation,  and  subject,  Tc  help  the  user 
unfamiliar  with  the  area,  the  bibliography  contains  brief, 
basic  reference  lists  in  the  areas  of  software  engineering, 
the  psychology  of  software  development,  the  Structured 
Programming  Series,  and  the  DoD  software  program.  Coverage 
is  exhaustive  through  1977  with  a  few  references  rrom  1978. 
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4. 


Atwood ,  M.E.  et  al.  An  exploratory  study  of  the  cognitive 
structures  underlying  the  comprehension  of  software  design 
problems.  Tech  Rep  392,  Englewood,  Colorado:  Science 
Applications,  Inc.,  July  1979. 

An  experiment  was  conducted  to  evaluate  a  framework 
for  the  study  of  software  complexity  and  comprehension.  Basic 
to  this  framework  is  the  concept  that  a  person's  knowledge  of, 
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ability  to  comprehend  a  software  problem  and  its  potential 
solutions.  Past  research  on  software  complexity  and  comprehensi¬ 
bility  has  largely  been  based  on  the  assumption  that  complexity 
is  a  function  of  surface  properties,  such  as  variable  names  and 
flow  of  control.  Such  measures,  however,  ignore  the  effects  of 
experience. 

Research  on  expert-novice  differences  in  problem* 
solving  suggests  that  experts  possess  a  large  number  of  previously 
developed  knowledge  structures,  or  schemata,  that  can  be  used 
to  understand  or  solve  the  current  problem.  Research  on  text 
comprehension  provides  theoretical  concepts  and  experimental 
paradigms  that  are  useful  in  determining  the  structure  and 
content  of  these  experience-related  schemata. 

An  experiment  examined  the  knowledge  structures  used 
by  participants  at  differing  levels  of  experience  in  comprehending 
software  system  specifications.  Six  participants,  at  each  of 
five  levels,  studied  a  software  system  specification  and  then 
summarized  both  the  presented  specification  and  the  probable  form 
of  the  corresponding  software  design.  The  results  indicate  that 
software  designers  use  previously  learned  schemata  in  understanding 
a  software  design  problem  and  in  actually  constructing  a  design, 
and  that  these  schemata  differ  as  a  function  of  experience.  In 
addition,  the  structure  and  content  of  these  schemata  were 
investigated.  It  is  suggested  that  by  determining  the  structure 
and  content  of  such  schemata,  software  complexity  and  compre¬ 
hensibility  can  be  considered  in  a  more  meaningful  manner. 


5.  Bruce,  B.C.  Case  systems  for  natural  language.  BBN  Rep  No.  3010. 

Cambridge,  MA:  Bolt,  Beranek  and  Newman,  Inc.,  April  1975  . 

In  many  languages  (e.g.,  Latin,  Greek,  Russian, 

Turkish,  German)  the  relationship  of  a  noun  phrase  to  the 
rest  of  a  sentence  is  indicated  by  altered  forms  of  the  noun. 

The  possible  relationships  are  called  (surface)  "cases".  Because 
(1)  it  is  difficult  to  specify  semantic-f ree  selection  rules 
for  the  cases,  and  (2)  related  phenomena  based  on  prepositions 
or  word  order  appear  in  apparently  case-less  languages,  many 
have  argued  that  studies  of  cases  should  focus  on  meaning,  i.e. 
on  "deep  cases" . 

Deep  cases  bear  a  close  relationship  to  the  modifiers 
of  a  concept.  In  fact,  one  could  consider  a  deep  case  to  be 
a  special  or  distinguishing  modifier.  Several  criteria  for 
recognizing  deep  cases  are  considered  here  in  the  context  of 
the  problem  of  describing  an  event.  Unfortunately,  none  of 
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the  criteria  serves  as  a  completely  adequate  decision  procedure. 
A  notion  based  on  the  context-dependent  "importance”  of  a 
relation  appears  as  useful  as  any  rule  for  selecting  deep  cases . 

A  representative  sample  of  proposed  case  systems  is 
examined.  Issues  such  as  surface  versus  deep  versus  conceptual 
levels  of  cases,  and  the  efficiency  of  the  representations 
implicit  in  case  systems  are  also  discussed. 


6.  Dzida,  W.;  Herda,  S.  &  Itzfeldt,  W.D.  User-perceived  quality 
of  infprarf i vp  systems.  IEEE  Transactions  on  software 
engineering,  1978,  SE4(4),  270-276. 

User-perceived  quality  of  interactive  systems  is 
defined  in  terms  of  statistically  nonoverlapping  categories, 
so-called  dimensions  or  factors.  Categories  are  identified  by 
factor  analysis  and  represent  a  dimensional  concept  of  the 
quality  of  interactive  systems  as  perceived  by  its  users.  Each 
category  describes  essential  user  requirements . 

This  paper  reports  on  a  method  and  some  initial  results 
in  the  analysis  of  user-perceived  quality  of  interactive  systems. 
It  is  based  on  research  work  described  in  more  detail  elsewhere. 

The  methodology  of  approach  is  suitable  for  software 
requirements  definition  and  human  factors  engineering. 


7.  Foley,  J.D.  Sl  Wallace,  V.L.  The  art  of  natural  graphic  man- 

machine  conversation.  In  Proceedinas  of  the  IEEE,  April  1974, 
62(4),  462-471. 

The  design  of  interactive  graphic  systems  whose  aim 
is  good  symbiosis  between  man  and  machine  involves  numerous 
factors.  Many  of  those  factors  can  be  judged  from  the 
perspective  of  natural  spoken  conversation  between  two  people. 

Guiding  rules  and  principles  for  design  of  such  systems 
are  presented  as  a  framework  for  a  survey  of  design  techniques 
for  man-machine  conversation.  Attention  is  especially  focused 
on  ideas  of  action  syntax  structuring,  logical  equivalences 
among  action  devices,  and  avoidance  of  psychological  blocks 
to  communication. 


8.  Gannon,  J.D.  An  experiment  for  the  evaluation  of  language  features. 

Int.  J.  man-machine  studies,  1976,  8,  61-73, 

Recently  a  number  of  experiments  have  been  performed 
whose  aim  was  to  compare  programming  language  features  to 
determine  which  programming  language  features  programmers  found 
difficult  to  use.  This  paper  examines  these  experiments  in 
light  of  the  evidence  that  programming  language  designers  would 
find  most  useful.  A  new  experiment  is  described  and  applied  to 
the  problem  of  whether  the  assignment  operation  should  be  defined 
as  an  operator  or  a  statement  designator.  Empirical  evidence  in 
the  form  of  errors  made  by  students  programming  solutions  to  two 
good-sized  problems  is  presented  favoring  the  use  of  assignment 
as  a  statement.  Finally,  the  shortcomings  of  the  new  experiment 
are  discussed. 
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9.  Greeno,  J.G.  The  structure  of  memory  and  the  process  of  solving 
problems.  In  R.L.  Solo  (Ed.),  Contemporary  issues  in  cognitive 
psychology:  The  Loyola  Symposium.  Washington:  Winston/Wiley, 

1973,  103-133. 

This  paper  explores  the  role  of  knowledge  structures 
and  memory  in  problem  solving.  A  brief  review  of  past  approaches 
to  problem  solving  and  the  degree  to  which  the  approaches 
involved  the  role  of  memory  is  presented.  Problem  solving  is 

T  *  2_  CT-'TC  d  franc  ■F/'M-m  i  <~r  4-V»o  i  m’  f  1  a  1  c  i  f  naf  i  Or* 

(or  given  variables)  into  the  desired  situation  (or  unknown 
variables) .  Both  givens  and  the  desired  situation  can  differ 
from  problem  to  problem  with  regard  to  how  well  they  are 
specified.  Productive  thinking  in  problem  solving  is  discussed 
in  terms  of  a  3-factor  theory  and  some  related  research  studies 
are  briefly  reviewed. 


10.  Halpern,  M.  Foundations  of  the  case  for  natural-language 
programming.  IEEE  Spectrum,  March  1967,  4(3),  140-149. 

The  purpose  of  this  paper  is  to  clarify  some  of  the 
misconceptions  that  impede  useful  discussion  of  the  question 
of  the  suitability  of  natural  language  for  programming.  It 
is  argued  that:  (1)  Natural-language  programming  is  an  attempt 
to  put  nonprogrammers  in  a  closer  relation  with  the  computer, 

(2)  A  natural  programming  language  must  be  able  to  be  written 
easily,  not  just  read  easily,  (3)  Processing  natural  language 
is  qualitatively  different  from  (and  faster  than)  translating 
one  language  to  another,  (4)  The  redundancy  of  natural 
language  is  an  advantage  rather  than  a  disadvantage,  and 
(5)  Natural  language  programming  will  help  bridge  the  man- 
machine  communication  gap. 


11.  Hill,  I.D.  Wouldn't  it  be  nice  if  we  could  write  computer 
programs  in  ordinary  English  -  or  would  it?  The  Computer 
Bulletin,  June  1972,  306-312. 

One  argument  that  is  frequently  made  in  favor  of 
natural-language  programming  is  that  people  should  be  able 
to  communicate  with  computers  in  the  same  way  that  they 
communicate  with  each  other.  While  it  is  desirable  to 
have  a  common  mode  of  communication,  this  does  r.ot  imply  that 
we  need  to  teach  computers  English;  an  alternative  is  to 
teach  people  to  communicate  with  each  other  through 
unambiguous  instructions.  This  paper  will  consider  the 
intricacies  in  natural  English  that  prohibit  natural  language 
and  simultaneously  illustrate  the  need  for  people  to  use 
programming  languages  in  their  interactions  with  others. 
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12.  Hoc,  J.M.  Role  of  mental  representation  in  learning  a  programming 
language.  Int.  J.  man-machine  studies,  1977,  9,  87-105. 

A  theoretical  framework  has  been  defined  to  elucidate 
the  problems  raised  in  the  training  of  analyst-programmers,  and 
a  beginning  made  in  validating  it  in  a  preliminary  experiment. 

This  experiment  showed  that  a  programming 

language  is  progressively  interiorized  by  a  subject  in  the  form 
of  a  "Systeme  de  Representation  et  de  Traitement"  (S.R.T.)  or 
"Representation  and  Processing  System",  in  which  the  experienced 
programmer  oau  cuiaxyze  prouiems.  Pnur  to  tins ,  nowever ,  ne  must 
have  made  his  analysis  in  other  S.R.T.  that  are  more  or  less 
compatible  with  the  programming  language  concerned.  Nineteen 
subjects  of  various  levels  of  training  were  made  to  construct 
a  COBOL  flowchart  of  a  Metro  ticket-machine  control  problem. 

An  analysis  of  errors  was  made  and  the  strategies  used  described 
with  the  aid  of  22  variables  in  order  to  determine  the  three 
principal  steps  involved  in  learning  a  programming  language. 


13.  Klein,  G.A.  &  Weitzenfeld,  J.  Improvement  of  skills  for  solving 
ill-defined  problems.  AFHRL-TR-78-31 ,  Brooks  AFB ,  Texas: 

AF  Human  Resources  Laboratory,  March  1979. 

To  develop  effective  programs  for  training  people  to 
solve  general,  commonly  encountered,  problems ,  it  is  necessary 
to  recognize  that  such  problems  are  typically  ill-defined  and 
require  additional  goal  specification.  Most  current  training 
programs  have  developed  from  information  processing  or  from 
Deweyan  theories  of  problem  solving.  However,  none  of  these  theories 
has  provision  for  dealing  with  ill-defined  problems.  Current 
programs  are  therefore  limited  in  their  applicability.  Solving 
ill-defined  problems  can  be  described  in  terms  of  two  interacting 
processes:  identifying  the  properties  of  the  goal,  and 

simultaneously  attempting  to  find  procedures  for  accomplishing 
the  goal.  Within  this  framework,  goal  specification  is  supported 
by  the  inference  of  goal  properties  from  analogous  problems, 
and  by  the  use  of  unsuccessful  procedures  for  inferring  goal 
properties.  This  description  of  how  people  solve  ill-defined 
problems  was  used  to  develop  a  number  of  implications  for 
training  programs  aimed  at  improving  problem  solving  abilities, 
such  as  the  need  to  train  personnel  to  specify  goal  properties 
initially  and  also  continually  throughout  the  process,  special 
opportunities  for  using  unsuccessful  hypotheses  as  a  source  of 
goal  properties,  and  the  value  of  analogies  for  suggesting  goal 
properties . 
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14.  Meister,  D.  &  Farr,  D.E.  The  methodology  of  control  panel  design. 
AMRL-TR-66-28 ,  Wright  Patterson  AFB ,  Ohio:  Aerospace  Medical 
Research  Laboratories,  Sept.  1966. 

Nine  control  panel  drawings  were  developed  by  designers 
using  standard  design  criteria  from  a  designer’s  guide.  The 
drawings  were  then  evaluated  by  five  experts  representing  the 
disciplines  of  human  factors,  industrial  design,  maintainability 
and  reliability  engineering.  Sample  panels  were  mocked  up  and 
subjects  were  tested  in  operational  use  of  these  panels.  The 
major  results  of  the  overall  study  were  that  (1)  Designers 
manifest  a  high  degree  of  variability  in  developing  control  panel 
drawings  even  when  presented  with  a  standard  package  of  design 
information;  (2)  human  engineering  design  criteria  appear  to 
be  significant  only  in  relation  to  anticipated  operator  performance 
characteristics,  and  difficulties  in  applying  these  criteria  stem 
from  lack  of  empirical  knowledge  of  these  relationships;  (3)  a 
major  source  of  difficulty  in  securing  the  application  of  human 
engineering  design  criteria  by  designers  is  the  latters ’  lack 
of  a  system-behavioral  approach  to  design.  The  major  need  in 
the  control  panel  design  area  is  empirical  research  to  refine 
and  standardize  simple  and  quickly  applied  evaluation  techniques. 
More  information  is  needed  concerning  the  manner  in  which 
designers  utilize  human  factors  and  other  design  inputs. 


15.  Meldman,  J.A.  A  new  technique  for  modeling  the  behavior  of  man- 
machine  information  systems.  Sloan  Management  Review,  Spring 
1977,  29-46  . 

A  serious  problem  in  understanding  or  designing  man- 
machine  systems  is  the  lack  of  powerful  formal  techniques  for 
modeling  or  describing  man-machine  interactions.  This  paper 
focuses  on  man-machine  interactions  in  management  information 
systems.  A  management  information  system  has  four  crucial 
characteristics  that  complicate  modeling  —  a  large  number  of 
interacting  subsystems,  highly  parallel  behavior,  asynchronous 
coordination  of  subsystems,  and  alternative  behavior  of  subsystems. 
It  is  suggested  that  Petri  Nets  offer  a  technique  for  modeling 
that  is  formal  and  explicit,  highly  modular,  and  comprehensive, 
and  can  aid  in  better  understandina  man-machine  interactions. 


16.  Miller,  G.A.;  Galanter,  E.  &  Pribram,  K.H.  Plans  and  the 
structure  of  Behavior.  Holt,  Rinehart  &  Winston,  1960. 

This  book  is  considered  a  landmark  in  the  evolution  of 
the  study  of  cognition  and  behavior.  It  essentially  discusses 
the  notion  that  some  more  organized  control  than  simple  stimulus- 
induced  activation  is  necessary  to  account  for  information 
processing  capacities.  It  discusses  the  cognitive  control 
processes  -  plans  -  that  guide  behavior.  Tne  book  presents  a 
discussion  o!  plans  -  schemata  -  for  all  aspects  of  behavior, 
such  as  motor  skills  and  habits,  remembering,  speaking,  etc. 
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17.  Miller,  L.A.  Programming  by  non-programmers.  Int.  J.  man- 
machine  studies,  1974,  6,  237-260. 

Non-programmers  were  asked  to  organize  natural  English 
commands  of  a  laboratory  programming  language  into  programs  for 
solving  name-sorting  problems.  The  problems  differed  in  the  sort 
concept  to  be  programmed  (conjunction  vs.  disjunction)  and  in 
the  form  of  expression  of  the  letter  tests  to  be  made  on  the 
names  (affirmation  vs.  negation). 

Programming  performance  was  found  to  be  impaired 
with  disjunctive  concepts  and  with  letter  tests  involving  negation. 
Difterent  classes  of  program  structure  v»ci c  xuuii ict  c..d  were 
associated  with  certain  problem  conditions  and  error  measures . 

An  influence  of  prior  experience  with  procedures  on  performance 
was  suggested.  Program  debugging  and  testing  performance  was 
characterized. 


18.  Miller,  R.B.  Psychology  for  a  man-machine  problem-solving 

system.  TR  00.1246,  Poughkeepsie,  NY:  IBM  Corp.,  Feb.,  1965. 

This  paper  deals  with  the  use  of  computer  capabilities 
to  extend  human  capabilities  for  invention  and  discovery.  A 
programmatic  route  will  be  proposed  for  development.  The  first 
stage  in  this  route  will  be  an  analytic  enumeration  of  human 
abilities  and  liabilities  as  a  problem-solving  mechanism.  The 
second  stage  will  deal  with  an  analysis  of  human  information¬ 
handling  tasks.  These  two  stages  should  illuminate  system 
objectives,  while  at  the  same  time  options  for  designing 
the  man-machine  problem-solving  entity  become  clarified.  The 
result  will  be  an  intelligence-retrieval  system  combined  with 
logical  and  extraordinary  display  capabilities.  The  principal 
design  issues  will  be  revealed  as  indexing  content  and  structure 
and  display  symbologies.  An  important  (and  neglected)  dimension 
in  system  design  is  the  human's  ability  to  learn  and  think  in 
new  languages  and  symbologies. 


19.  Miller,  R.B,  Archetypes  in  man-computer  problem  solving. 

Ergonomics ,  1969,  12(4),  559-581. 

Information  systems  applied  to  operational  environments 
have  meaning  only  in  what  they  do  for  humans  performinq  tasks, 
whether  clerical,  technical  or  managerial.  Each  person's  job- 
position  entails  interaction  with  a  limited  set  of  categories 
of  variable  data.  By  "limited 11  is  meant  less  than  several  thousand, 
and  more  likely  several  hundred,  categories.  A  category  set 
associated  with  a  collection  of  tasks  performed  by  an  individual 
or  an  organization  may  be  called  a  category  domain.  This  concept 
makes  possiole  a  practicable  (in  size)  data  base  responsive  to 
support  human  tasks  in  human  (psychological)  time. 

An  analysis  of  human  problem-solving  tasks  reveals 
the  following  types:  simple  inquiry  and  update,  status  inquiry, 
briefing,  exception  detection,  diagnosis,  plannin i/choosing , 
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evaluating/optirnizing ,  constructing  (designing),  and  discovery. 
There  is  no  compulsive  ordering  of  these  on  a  complexity  scale. 
The  information  processing  structure  of  each  is  examined:  some 
common  denominators  among  this  set  reveal  five  underlying 
archetypes  of  interaction.  By  making  these  archetypes  explicit 
md  consistent  with  concepts  of  domain,  application  disciplines 
and  system  design  can  move  in  parallel  and  generate  a  simple, 
well-defined  language  structure  between  system  and  human  user. 


20.  Mitchell,  T.R.  Uncertainty  and  decision  making.  Tech  Rep  79-19, 
Seattle,  WA:  Univ.  of  Washington  (Dept,  of  Psychology) , 

Sept.  1979. 

This  final  report  on  3+  years  of  research  reviews 
studies  in  the  causes  of  uncertainty,  theoretical  developments 
in  uncertainty,  the  consequences  of  uncertainty  and  the 
applications  of  theory  to  uncertain  situations.  Further,  work 
on  a  contingency  model  for  selection  of  decision  strategies  is 
outlined  and  related  research  is  described. 


21.  Norman,  D.A.  Memory,  knowledge  and  the  answering  of  questions. 

In  Solso,  R.  (Ed.)  Contemporary  issues  in  cognitive  psychology: 

The  Loyola  Symposium^  Winston/Wiley,  1973,  135-165. 

Discusses  the  nature  of  memory,  concluding  that  the 
stored  representation  of  knowledge  cannot  be  separated  from 
the  uses  to  which  the  knowledge  is  put.  Consideration  is  given 
to  the  learning  process, emphasizing  the  necessary  interaction 
between  learner  and  instructor.  The  learner  must  be  questioned 
to  see  what  information  is  lacking;  the  information  is  then 
provided;  and  then  requestioning  must  occur  to  evaluate  success 
of  the  desired  information  transfer.  This,  with  related 
considerations,  leads  to  the  formulation  of  a  theory  of  instruction 
which  highlights  the  importance  of  properly  connecting  new 
material  into  the  framework  provided  by  previous  information 
storage.  A  formal  structure  for  representing  semantic  information 
is  presented,  with  examples,  and  a  test  of  the  structure  utilizing 
simulation  on  a  digital  computer  is  described. 


22.  Posner,  M.I.  Cognition:  Natural  and  artificial.  In  Solso,  P. 

( Ed . )  Contemporary  issues  in  :ognitive  psychology:  The  Loyola 
Symposium.  Winston/Wiley,  1973,  167-174. 

This  paper  outlines  some  of  t\a  relationships  among 
the  papers  included  in  the  Solso  edited  volume,  and  compares 
current  cognitive  psychology  with  that  of  100  years  ago.  It  is 
pointed  out  that  whereas  psychologists  tend  to  split  the  world 
into  perceptual  and  linguistic  domains,  scientists  workina  with 
artificial  intelligence  rely  upon  similar  programs  to  handle 
both.  This  is  seen  as  possibly  su  nest  mu  a  fundamental 
difference  between  artificial  and.  natural  intel  1  ieenco . 
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23.  Ramsey,  H.R.  &  Atwood,  M.E.  Human  factors  in  computer  systems: 
a  review  of  the  literature.  Tech  Rep  SAI-79-111-DEN. 

Englewood,  Colorado:  Science  Applications,  Inc.,  Sept.  1979. 

Based  on  an  extensive  literature  survey,  this  document 
presents  a  description  and  critical  analysis  of  the  state  of  the 
art  in  the  area  of  human  factors  in  computer  systems.  This 
review  is  concerned  both  with  the  status  of  human  factors  research 
in  the  area  of  user-computer  interaction  and  with  the  current 
state  of  user-computer  interaction  technology  and  practices. 

The  primary  purpose  of  the  review  is  to  determine  whether 
research  and  practice  in  this  area  have  evolved  sufficiently 
to  support  the  development  of  a  human  factors  guide  to  computer 
system  design.  It  is  concluded  that  insufficient  data  exist 
for  the  development  of  a  "quantitative  reference  handbook"  in 
this  area,  but  that  a  "human  factors  design  guide"  —  which 
discusses  issues,  alternatives,  and  methods  in  the  context 
of  the  design  process  —  is  both  feasible  and  needed. 


24.  Ramsey,  H.R.;  Atwood,  M.E.  &  Campbell,  G.D.  An  analysis  of 
software  design  methodologies.  Tech  Rep  401.  Englewood, 
Colorado:  Science  Applications,  Inc.,  Aug.  1979. 

Four  formal  software  design  methodologies  were  described 
and  briefly  analyzed:  (1)  Structured  Design,  (2)  Jackson's 
Methodology,  (3)  Integrated  Software  Development  System  (Higher 
Order  Software) ,  and  (4)  Warnier’s  "Logical  Construction  of 
Programs."  Relative  strengths  and  weaknesses  and  commonalities 
among  the  methods  were  identif  ied,  and  human  factors  problem 
areas  were  analyzed. 

Several  major  human  factors  deficiencies  and  problems 
were  identified.  Formal  software  design  methods  differ  in 
terms  of:  Applicability  to  problems  of  different  types,  size 
or  complexity;  susceptibility  to  design  errors;  and  constraints 
and  limitations  imposed  on  the  software  designer.  Various 
methods  limit  the  designer's  ability  to  select  an  appropriate 
problem  representation,  prevent  the  designer  from  utilizing 
relevant  knowledge  and  experience,  or  impose  potentially 
significant  information  loads  on  the  designer.  Improvements 
in  design  methodologies  require  a  better  understanding  of  the 
problem-solving  behavior  of  software  designers;  potential 
research  topics  in  this  area  were  identified. 


25.  Ramsey,  H.R.;  Atwood,  M.E.  &  Kirshbaum,  P.J.  A  critically 
annotated  bibliography  of  the  literature  of  numun  factors 
in  computer  systems.  Tech  Rep  SAI-78-070-DE:: .  malewood, 
Colorado:  Science  Applications,  Inc.,  May  1??8. 

A  very  broad  survey  of  the  literature  doa linu  with 
human  factors  in  computer  systems  was  performed.  Included  in 
the  survey  were  books,  journal  articles,  proceedings  papers 
and  institutional  publications  from  the  literatures  of 
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psychology,  human  factors,  and  computer  science.  From  the 
resulting  list,  564  references  were  selected  for  inclusion  in 
this  bibliography.  The  references  selected  deal  primarily  with 
the  human  factors  aspects  of  interactive  computer  systems, 
including  hardware,  software  and  procedures.  The  selection  of 
references  emphasizes  experimental  studies,  but  the  biblio¬ 
graphy  also  includes  relevant  descriptions  of  dialogue  techniques, 
user  requirements  analysis  methods,  guidelines,  and  a  variety  of 
other  relevant  topics. 

For  each  reference,  a  citation  is  previously  included 
together  with  infnrniaf inn  t*n  allow  the  reader  to 

obtain  a  copy,  a  descriptive  abstract  and  a  critical  annotation. 

An  extensive  subject  index,  as  well  as  an  author  index  and 
browsing  aids,  allow  the  users  to  locate  those  articles  in  which 
they  are  interested. 


26.  Ramsey,  H.R.;  Atwood,  M.E .  &  Willoughby,  J.K.  Paper  simulation 

techniques  in  user  requirements  analysis  for  interactive  computer 
systems.  In  Proceedings  of  the  Human  Factors  Society  23rd  Annual 
Meeting .  Santa  Monica,  CA:  Human  Factors  Society,  1979. 

This  paper  describes  the  use  of  a  technique  called 
"paper  simulation"  in  the  analysis  of  user  requirements  for 
interactive  computer  systems.  In  a  paper  simulation,  the  user 
solves  the  problems  with  the  aid  of  a  "computer",  as  in  normal 
man-in-the-loop  simulation.  In  this  procedure,  though,  the 
computer  does  not  exist,  but  is  simulated  by  the  experimenters. 

This  allows  simulated  problem  solving  early  in  the  design  effort, 
and  allows  the  properties  and  degree  of  structure  of  the  system 
and  its  dialogue  to  be  varied.  The  technique,  and  a  method 
of  analyzing  the  results,  are  illustrated  with  examples  from  a 
recent  paper  simulation  exercise  involving  a  Space  Shuttle  flight 
design  task. 


27.  Schrenk,  L.P.  Aiding  the  decision  maker  -  A  decision  process 
model.  Ergonomics ,  1969,  12(4),  543-557. 

Despite  an  increasing  capacity  for  automating  various 
tasks, there  continues  to  be  a  requirement  for  man  to  serve  as  the 
decision  element  in  many  complex  systems.  The  complexity  and  far- 
reaching  consequences  of  many  decisions  impels  a  concern  for 
improving  decision-making  performance  in  man-machine  systems. 

In  this  paper  current  knowledge  regarding  human  decision  behavior 
and  methods  for  aiding  this  behavior  are  briefly  reviewed.  A 
tentative  conceptual  model  of  an  idealized  process  of  decision 
making  is  presented.  This  model,  which  is  based  on  both  empirical 
and  theoretical  research,  contains  three  phases,  ^hesc  art 
(1)  problem  recognition,  (2)  problem  diacnor  •,  and  (3)  action 
selection.  The  model  is  intended  primarily  to  provide  a  guide 
to  system  designers  in  structuring  .iecision  tasks  and  a  framework 
for  organizing  knowledge  about  decision-making  behavior. 
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28.  Shneiderman,  B.  &  Shapiro,  S.C.  Toward  a  theory  of  encoded  data 
structures  and  data  translation.  Int.  J.  of  computer  and 
information  sciences,  1976,  5(1),  33-43. 

Several  models  of  data  base  systems  have  distinguished 
levels  of  abstraction  ranging  from  the  high-level  entity  set 
model  down  to  the  low-level  physical  device  level.  This 
paper  presents  a  model  for  describing  data  encodings,  an 
intermediate  level  which  focuses  on  the  relationship  among  data 
items  as  demonstrated  by  contiquity  or  by  pointer  connections. 
Multiple  data  encodings  for  a  file  are  shown  and  transformation 
functions  that  describe  the  translation  between  data  encodings 
are  discussed. 


29.  Smith,  S.L.  Requirements  definition  and  design  guidelines  for 

the  man-machine  interface  in  system  acquisition.  Rep  M80-10. 
Bedford,  MA:  M1TRF.  Corp.,  April  15,  1980. 

This  report  is  both  a  review  of  the  tate-of-the-art 
of  man-machine  interface  (MMI)  in  CJ  systems  and  a  proposal 
for  the  exploration  of  potential  development  and  application 
of  MMI  design  guidelines  in  Air  Force  C3  systems  acquisition. 

The  report  discusses  requirements  definition,  including 
consideration  of  user/operator  characteristics,  the  information 
handling  requirements  of  people's  jobs,  and  the  functional 
capabilities  that  can  be  provided  in  the  MMI.  It  then  discusses 
the  problem  of  developing  specifications  that  will  communicate 
functional  requirements  to  the  systems  designer,  giving  a  sample 
set  of  guidelines.  The  report  further  discusses  the  specific 
documentation  of  MMI  design  that  will  be  needed. 


3C .  Whalen,  G.V.  &  Askren,  W.B.  Impact  of  design  trade  studies  on 
system  human  resources.  AFHRL-TR-74-89 ,  Brooks  AFB ,  Texas: 

AF  Human  Resources  Laboratory,  Dec.  1974. 

This  study  was  undertaken  to  accomplish  two  objectives. 

The  first  objective  was  to  identify  and  classify  the  characteristics 
of  conceptual  design  trade  studies  that  have  hioh  potential  impact 
on  human  resource  requirements  of  Air  Force  weapon  systems. 

The  approach  used  was  a  case  history  review  and  analysis  of  129 
F-15  aircraft  design  trade  studies.  The  analysis  indicated  that 
the  avionics  system  demonstrated  the  greatest  potential  impact 
on  human  resources.  It  was  also  found  that  trade  studies  dealing 
with  design  alternatives  that  encompass  widely  different 
technologies  have  substantial  impact  on  human  resources.  The 
types  of  human  resources  data  (HRD)  most  influenced  by  alternative 
design  options  were  maintenance  task  times  and  personnel  costs. 

The  second  study  objective  was  to  determine  the  accuracy  of 
using  subjective  estimates  as  a  technique  for  derivi.no  HRD  impact 
of  trade  study  options.  Using  only  engineeri no  information  for 
six  avionics  subsystems  from  the  conceptual  desiur.  phase.  Air 
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Force  maintenance  technicians  made  subjective  estimates  of  the 
impact  of  the  designs  on  selected  HRD  items.  It  was  found  that 
technicians  made  highly  accurate  estimates  of  the  amount  of  time, 
the  Air  Force  occupational  specialty,  the  level  of  technical  skill, 
and  the  number  of  personnel  needed  to  perform  field  maintenance 
tasks . 


31.  Wickelgren,  W.A.  Cognitive  psychology.  Englewood  Cliffs,  NJ : 

i  .•  ^  -r  i  mo 

*  •  ,  —  -  *  -  • 

The  book  attempts  to  summarize  and  synthesize  knowledge 
about  how  the  mind  works  within  an  integrated  theoretical 
framework.  The  approach  is  a  consistent  combination  of  what  the 
author  considers  to  be  the  best  parts  of  associative,  structural- 
linr‘4Sbistic,  and  information  processing  approaches  to  the  mind. 

The  chapters  cover  such  topics  as:  visual  perception;  spatial 
cognition  and  imagery;  auditory  perception;  speech  and  reading; 
attention;  short-term  memory;  associative  long-term  memory; 
retrieval;  recall  and  recognition;  semantic  memory  coding: 
concepts,  propositions  and  schemata;  semantic  memory  processes: 
retrieval,  learning  and  understanding;  and  thinking:  plans,  infer¬ 
ence,  problem  solving  and  creativity. 


32.  Woods,  W.A.  What's  in  a  link:  Foundations  for  semantic  networks 
In  Bobrow,  D.G.  &  Collins,  A.  (Eds.}  Representation  and 
understandina :  Studies  in  cognitive  science.  Academic  Press, 

wrr. - - -  - - - 


This  paper  explores  the  topic  of  semantic  networks 
and  the  degree  tc  which  they  are  capable  of  representing  knowledge. 
The  chapter  is  organized  into  3  major  sections.  The  first  discusses 
the  concept  of  semantics,  including  misconceptions  about  semantics 
and  the  semantics  of  programming  languages.  The  second  section 
discusses  semantic  networks  presenting  requirements  for  semantic 
representation,  and  the  approaches  such  as  links  and  case 
representations.  The  third  section  explores  various  problems 
in  knowledge  representation. 
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APPENDIX  D 

REVIEW  OF  RESEARCH  RELATED  TO  HUMAN- 
COMPUTER  INTERACTIONS 


Appendix  C  reviewed  psychological  literature  related  to  the 
engineering  design  process  —  that  is,  the  process  that  an 
individual  engineer  might  go  through  in  developing  design 
concepts.  In  doing  so  the  review  focussed  on  the  cognitive 
processes  of  the  individual  designer  in  developing  system 
concepts.  Appendix  D  reviews  research  relating  to  the 
weapon  system  design  process,  which  is  a  more  general 
process  relating  to  the  overall  development  of  the  system. 
The  weapon  system  design  process  involves  a  large  number  of 
different  individuals  in  several  different  disciplines  who 
are  scattered  across  rany  different  Army  and  contractor 
organizations.  As  waj  noted,  one  of  the  major  problems 
surrounding  the  weapon  system  design  process  is  the 
communication  and  flow  of  information  among  the  participants 
in  this  more  general  process.  The  ETES  SDT  is  specifically 
designed  to  deal  with  these  communication  problems  by 
providing  a  centralized,  automated  data  base  for  describing 
and  updating  emerging  system  concepts  and  providing  direct 
access  to  this  data  base  to  all  participants  in  the  weapon 
system  design  process.  Thus,  the  SDT  provides  a  systematic 
vehicle  through  which  the  participants  in  the  weapon  system 
design  may  communicate  (see  Figure  D-l ) .  To  provide  a 
foundation  for  SDT  development  this  appendix  reviews 
research  relating  to  the  SDT's  role  as  a  data  base 
management  system  and  communication  tool. 

The  appendix  is  divided  into  two  major  sections.  The  first 
section  describes  the  SDT  requirements  related  to  human- 
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Figure  0-1  CENTRAL  COMMUNICATION  ROLE  OF  SOT 


computer  interactions.  The  second  section  reviews 
psychological  research  relating  to  the  process  of  human- 
computer  interactions  and  summarizes  the  implications  that 
this  literature  has  for  the  SDT. 

D.l  SDT  REQUIREMENTS  RELATED  TO  HU MAN -COMPUTER  INTERACTIONS 

Section  1.0  reviewed  the  problems  in  information  flow  and 
communication  which  led  to  the  initiation  of  the  ETES 
project.  Briefly,  it  was  pointed  out  that  training 
developers  and  other  participants  in  the  acquisition  process 
are  not  systematically  receiving  information  on  early  system 
concepts  and  are  not  being  kept  abreast  of  system  changes 
and  updates  in  a  timely  and  systematic  fashion.  This  lack 
of  systematic  communication  makes  it  difficult,  if  not 
impossible,  to  effectively  assess  training  and  other  human 
resources,  and  this  lack  of  assessment,  in  turn,  makes  it 
difficult  to  effectively  manage  and  control  these  resources. 

In  order  for  the  SDT  to  fill  these  communication 
deficiencies,  the  SDT  must  itself  be  designed  to  facilitate 
easy  and  rapid  communication  with  the  personnel  who  will  use 
it.  Reviewing  Appendix  A,  it  is  clear  that  the  primary 
users  of  the  SDT  will  be  personnel  from  the  staff  of  the 
training  developers,  combat  developers,  and  materiel 
developers.  These  personnel  are  likely  to  have  had  little, 
if  any, .  experience  in  utilizing  computers  or  computerized 
data  bases.  Interviews  with  current  commanders  in  these 
organizations  indicates  that  there  is  also  likely  to  be  very 
little  time  or  resources  to  train  these  personnel  on  ETES- 
related  activities.  Thus,  it  is  imperative  that  the  SDT  be 
designed  to  (1)  be  utilized  by  uninitiated  users  who  have  no 
background  in  the  use  of  computers  and  computer  languages 
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and  (2)  have  minimal  training  requirements.  Fortunately,  in 
recent  years  there  has  been  a  growing  body  of  literature  on 
human-computer  interactions  and  the  types  of  interactions 
which  are  appropriate  for  uninitiated,  minimally  trained 
users.  This  literature  is  reviewed  in  the  subsections  which 
follow. 

Before  discussing  this  literature,  it  is  important  to  point 
out  that  the  systematic  study  of  human-computer  interactions 
is  a  relatively  new  area  of  research.  Consequently,  many  of 
the  guidelines  discussed  in  the  next  section  are  only 
rational  schemes  for  dealing  with  human- computer 
interactions  —  empirical  research  to  support  these 
guidelines  is  generally  not  available.  However,  the 
conceptual  schemes  which  have  been  developed  do  appear  to 
have  a  high  degree  of  face  validity  and  should  provide  the 
necessary  framework  for  the  development  of  the  SDT • 

D.2  MAN-DATA  BASF  INTERACTION  LITERATURE  REVIEW 

There  have  been  four  major  efforts  to  survey  and  categorize 
literature  relating  to  human-data  base  interactions.1  More 
details  on  these  four  efforts  is  presented  in  the 
subsections  which  follow. 

D.2.1  -  Martin's  Work  on  Interactive  Dialogues 

The  first  comprehensive  work  in  human-computer  interactions 
was  conducted  by  Martin  (1973)  Who  documented  his  work  in  a 


1  This  research  area  is  also  described  as  the  "man-machine 
interface"  (MMI),  as  well  as  the  human-computer  interface  or 
interaction. 
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book  on  human-computer  dialogues.  Martin's  book  was  the 
first  attempt  to  provide  a  systematic  set  of  guidelines  or 
human-computer  interactions.  Earlier  work  had  focussed  on 
the  development  of  guidelines  for  computer  input  devices  or 
output  devices  or  computer  programming  practices  but  had  not 
systematically  covered  dialogue  or  process-related 
questions. 

Martin's  basic  approach  toward  conceptualizing  the  human- 
computer  interactions  was  to  divide  human-computer 
interations  into  18  basic  dialogue  types  and  to  outline  the 
advantages  and  disadvantages  of  each  type  in  terms  of  types 
of  users  and  information  characteristics.  Table  D-l 
displays  Martin's  dialogues  types  and  the  estimated 
applicability  to  the  SDT  based  upon  Martin  description  of 
their  advantages  and  disadvantages.  As  Table  0-1  indicates, 
the  most  likely  dialogues  types  for  inclusion  in  the  SDT  are 
menu  selection  dialogues,  form-filling,  and  question  and 
answer  dialogues.  These  were  the  dialogues  which  Martin 
indicated  were  (1)  most  appropriate  for  uninitiated  users 
and  (2)  would  not  require  extensive  development  costs  or 
special  terminals. 

Martin  also  provides  a  series  of  guidelines  to  consider  in 
selecting  input  and  output  devices.  Table  D-2  lists  the 
input  and  output  devices  covered  by  Martin.  To  reduce 
implementation  costs,  it  is  desirable  that  th*  SDT  utilize 
equipment  that  is  currently  available  in  ETES-related 


2  Martin  presents  little  empirical  evidence  to  support  his 
concepts  (very  little  work  has  been  done  in  this  area). 
However,  his  concepts  appear  logical  and  seem  to  have  a  high 
degree  of  "face  validity." 
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Table  D-l 

MARTIN’S  DIALOGUE  TYPES  AND  THEIR  APPLICABILITY  TO  SDT* 


1.  Programming  languages 

2.  English-language  dialogue 

3.  Limit  English  input 

*4.  Question  and  answer  dialogues  (in  which  the  computer  asks  the  operator 
a  series  of  questions) 

5.  Dialogue  using  mnemonics 

6.  Dialogue  with  programming-like  statements 

7.  Computer-initiated  dialogues  (in  which  the  operator  responds  to  the  computer 
rather  than  the  computer  responding  to  the  operator) 

*8.  Form-filling  (in  which  the  operator  fills  out  a  "f^rm"  on  a  visual  display) 

*9.  Menu-selection  dialogues 

10.  Build  dialogue  features  into  special  terminal  hardware 

11.  Dialogues  with  a  light  pen  for  input  (or  other  means  of  pointing  to  the 
screen ) 

12.  Fixed-panel  responses  (in  which  the  computer  responds  with  one  of  a  standard 
set  of  panels) 

13.  Modifiable-panel  dialogues  (in  which  the  panels  can  be  modified  by  the 
programs) 

14.  Graphics  using  chart  displays 

15.  Graphics  using  symbol  manipulation 

16.  Dialogues  with  photographic  frames 

17.  Voice  answerback  dialogues 

18.  Dialogue  via  a  third  party 


♦Items  applicable  to  SDT. 


Tabic  D-2 


MARTIN’S  CATEGORIZATION  OF  INPUT-OUTPUT  DEVICES 
AND  THEIR  APPLICABILITY  TO  THE  SDT 


Input 

♦Keyboard 
Lever  set  or 
Rotary  switches 
Push  buttons 

Light  pen  for  point  at  screen 
Finger  pointing  at  screen 
Stylus  for  drawing 
Plate  reader 
Badge  reader 

♦Applicable  to  SDT. 


Output 

♦Typewriter  or  printer 
Alphanumeric  screen 
♦Graphics  screen 
Screen  displaying  film  frames 
Light  panel 
Graph  plotter 
Dials 

Voice  answerback 
Facsimile  machine 
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organization.  This  requires  that  the  SDT  interactive  input 
device  mechanisms  be  restricted  to  a  keyboard  and  output 
devices  mechanisms  be  restricted  to  a  printer  and  a  graphics 
screen. 

Finally,  it  is  interesting  to  note  that  Martin  suggests  that 
in  the  future,  "most  dialogue  programs  will  be  generated 
with  dialogue  program  generators  rather  than  being 
programmed  in  a  conventional  language."  These  dialogue 
program  generators  are  currently  being  used  in  computer- 
assisted  instruction  and  are  desirable  because  they  reduce 
the  programming  that  is  needed  for  user-friendly  dialogue. 
These  types  of  programming  techniques  should  also  be 
considered  during  construction  of  the  SOT. 

D.2.2  -  Ramsey  and  Atwood's  Work  on  Human  Factors  in 
Computer  Systems 

Another  major  effort  in  systematically  assessing  human- 
computer  interactions  was  directed  by  H.  Rudy  Ramsey  and 
Michael  Atwood  in  work  sponsored  by  the  Engineering 
Psychology  Programs  of  the  Office  of  Naval  Research.  Ramsey 
and  Atwood  (1979)  have  developed  a  conceptual  scheme  for 
classifying  different  areas  of  research  relating  to  human- 
computer  interactions.  Table  D-3  presents  this  scheme  and 
also  indicates  which  Atwood  and  Ramsey  categories  are  most 
relevant  to  the  SDT  development.  It  is  important  to  point 
out  that  input  and  output  device  questions  are  less  relevant 
to  the  SDT  because  the  SDT  will  utilize  existing 
input/output  devices  and  thus  the  interactive  input  device 
for  the  SDT  is  likely  to  be  a  keyboard  and  the  interactive 
output  devices  are  likely  to  be  a  printer  and  terminal 


implications  of  dialogue  methods  for  input  device  selection; 
selection  or  design  of  input  devicc(x). 

Evaluation  of  system  performance:  use  of  subjective  evaluations, 
objective  performance  measures. 


display.  In  the  sections  which  follow,  more  details  on 
these  categories  of  research  are  reviewed. 

•  User  Characteristics 

In  discussing  user  characteristics  Ramsey  and  Atwood  review 
several  past  articles  which  have  dealt  with  the  requirements 
and/or  capabilities  of  uninitiated  users,  (e.g.,  Card  et  al, 
1974;  Eason,  et  al  1975;  Evans,  1976;  Martin,  1973; 
Nickerson  and  Pew,  1971;  and  Thompson,  1971).  Atwood  and 
Ramsey  indicate  that  interactions  by  these  users  can  be 
facilitated  if  the  computer-initiated  or  natural  language 
dialogues  are  used,  and  they  point  out  that  natural  language 
dialogues  are  very  expensive  to  develop. 

Atwood  and  Ramsey  also  discuss  a  procedure  developed  by 
Nawrocki,  et  al  (1973)  for  conducting  an  automated  error 
analysis.  The  error  analysis  can  provide  the  means  for 
improving  system  performance  and  might  be  useful  during  SDT 
implementation . ^ 

•  Tasks 

Ramsey  and  Atwood's  discussion  of  human-computer  tasks 
centers  on  the  development  of  task  taxonomies  which  can  be 
applied  to  computer-related  tasks.  This  issue  can  be 
subsumed  under  the  more  general  issue  of  the  development  of 
a  task  taxonomy  applicable  to  all  weapon  system  behaviors. 
This  issue  will  be  examined  in  later  phases  of  SDT 


3  However,  as  Strub  (1975)  has  pointed  out  many  errors  are 
not  detectable  by  such  automated  techniques. 
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development.  Hence  Ramsey  and  Atwood  review  of  this  area, 
which  actually  does  little  in  the  way  of  suggesting  a 
possible  taxonomy,  is  not  reviewed  here. 

•  Requirements  Analysis 

A  discussion  of  requirements  analysis  tools  is  presented  in 
Section  3.  Hence,  Ramsey  and  Atwood's  discussion  is  not 
repeated  here. 

•  Interactive  Dialogue 

As  was  noted  earlier,  Ramsey  and  Atwood  indicate  that 
computer-initiated  dialogue  would  seem  to  a  much  more 
effective  means  of  communication  with  uninitiated  users,  who 
are  exactly  the  type  of  users  which  will  utilize  the  SDT . 

Ramsey  and  Atwood  point  out  that  computer-initiated  dialogue 
has  several  advantages.  First,  this  approach  to  dialogue 
allows  the  system  to  rely  on  the  passive  vocabulary  of  the 
user  (the  set  of  words  which  the  user  can  recognize  and 
understand),  which  is  typically  much  larger  than  the  user's 
active  vocabulary  (words  which  the  user  can  generate  and  use 
without  prompting).  Second,  it  allows  the  designer  to 
implicitly  convey  to  the  user  a  "mental  model"  of  the 
system's  dialogue  structure.  The  major  disadvantage  of 
computer-initiated  dialogue  is  the  frequent  delay  it  may 
produce  for  experienced  users. 

Ramsey  and  Atwood  also  present  a  scheme  for  classifying 
different  types  of  interactive  dialogues,  and  list  the 
advantages  and  disadvantages  of  each  type.  A  summary  of 
this  discussion  is  presented  in  Table  D-4.  Two  types  of 
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Table  D-4 

RAMSEY  AND  ATWOOD'S  SCHEME  FOR  CLASSIFYING  DIALOGUE  TYPES* 
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♦Table  derived  from  Ramsey  and  Atwood  (1979). 


dialogue  seem  especially  applicable  to  the  SDT  because  of 
their  emphasis  on  computer-initiated  dialogue  —  form¬ 
filling  and  menu-selection.  Another  dialogue  type  query 
languages-would  appear  to  be  relevant  to  the  SDT  because  of 
its  close  ties  to  data  base  management  systems. 

Form-filling  is  often  used  in  situations  in  which  the  user's 
input  is  dominated  by  parameter  values,  rather  than 
commands.  Many  attributes  involve  this  type  of  data. 
Hence,  form-filling  would  appear  to  be  particularly  useful 
as  a  data  input  mechanism  for  attributes. 

Menu  selection  is  described  by  Ramsey  and  Atwood  as  the 
"archetype  of  computer-initiated  dialogue."  Unlike  question 
and  answer  dialogue  or  form-filling,  all  of  the  items  to  be 
selected  appear  on  the  screen,  and  thus  the  user  need  only 
recognize  the  desired  action.  Also,  a  simple  menu-selection 
dialogue  ordinarily  requires  only  one  user  input  (on  the 
keyboard  or  screen),  rather  than,  for  example,  the  series  of 
keystrokes  required  to  type  a  whole  word.  Redsdale  (1970) 
reports  a  study  which  documented  the  effectiveness  of  menu- 
selection  with  naive  users.  The  study  indicated  that  menu 
selection  was  especially  effective  when  used  as  means  of 
obtaining  answers  to  a  set  of  branching  questions. 

It  is  especially  important  to  note  that  menu  selection  is  a 
highly  effective  dialogue  method  for  hierarchic  search 
because  of  its  reliance  on  the  user's  passive  vocabulary  and 
recognition  memory.  Hence,  menu  selection  is  particularly 
applicable  to  information  retrieval  (see  Thompson,  1969, 
1979  for  a  more  extensive  discussion  of  menu  selection  as  a 
data  retrieval  mechanism) . 
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Query  languages  are  used  to  access  an  existing  data  base. 
According  to  Ramsey  and  Atwood,  studies  of  specific  query 
languages  have  generally  concluded  that  existing  query 
languages  can  be  utilized  by  untrained  users,  particularly 
if  the  system  in  which  the  language  is  embedded  emphasizes  a 
computer-initiated  approach.  However,  they  point  out  that 
the  error  rate  with  query  languages  can  be  high.  To  reduce 
error,  they  suggest  (1)  utilizing  a  layered  or  portioned 
query  language  (that  is,  a  query  language  which  utilizes  a 
lot  of  computer-initiated  dialogue)  (2)  restating  the  user's 
command  before  execution. 

•  Input/Output  Devices  and  Techniques 

As  noted  above,  the  restriction  of  SDT  hardware  to  computer 
equipment  currently  utilized  by  probable  ETES  users  requires 
that  SDT  input  devices  be  limited  to  the  keyboards  of 
existing  terminals  and  SDT  output  devices  be  limited  to 
printers  and  the  display  capabilities  of  existing 
terminals.  Because  of  these  restrictions,  most  of  Ramsey 
and  Atwood's  discussion  of  input/output  devices  and 
techniques  is  not  relevant.  However,  one  area  of  research 
that  is  relevant  is  the  discussion  of  techniques  for  coding 
information  on  CRT  screens.  The  literature  in  this  area  is 
quite  extensive  and  the  interested  reader  should  consult 
Ramsey  and  Atwood  for  a  review.  It  should  be  noted  that  the 
requirement  that  the  SDT  be  usable  on  a  range  of  existing 
terminals  severely  restricts  the  type  of  coding  that  can  be 
applied.  Only  very  simple  coding  techniques  (underlining, 
character  size  control,  etc.)  may  be  able  to  be  usable  on  a 
wide  range  of  terminals. 
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•  Evaluation  of  System  Performance 

Ramsey  and  Atwood's  discussion  of  the  evaluation  of  human- 
computer  systems  is  more  related  to  implementation  phase  of 
the  SDT  than  to  the  developmental  phase.  Hence,  it  is  not 
reviewed  here. 

D.2.3  Smith's  Work  on  Man-Machine  Interface 

Another  major  effort  related  to  the  assessment  of  human- 
computer  interactions  has  been  Sidney  Smith's  (1980)  work  on 
the  development  of  guidelines  for  the  man-machine  interface 
in  C3  systems.  This  work  was  sponsored  by  the  Air  Force 
Electronic  Systems  Command. 

Like  Ramsey  and  Atwood,  Smith  (1980)  has  developed  a  scheme 
for  categorizing  topic  areas  related  to  human- computer 
interactions.  Table  D-5  displays  Smith's  schemes  and  the 
categories  of  Smith's  work  which  have  the  most  applicability 
to  the  SDT.  Selected  aspects  of  Smith's  (1980)  major  report 
in  this  area  which  are  relevant  to  ETES  are  reviewed  below. 

•  Dialogue-Types 

Smith,  like  many  other  investigators  in  this  area,  notes 
that  computer-initiated  dialogue  types  (e.g.,  form-filling, 
menu-selection)  are  more  appropriate  for  uninitiated  users 
than  are  user-initiated  dialogues  (e.g.  programming 
languages).  Table  D-6  displays  Smith's  categorization  of 
the  different  dialogue  types  and  his  estimation  of  user 
training  and  response  time  associated  with  each  type.  Based 
upon  Smith's  estimates,  question  and  answer,  form-filling 
and  menu  selection  vould  seem  to  be  the  most  appropriate 


Table  D-5 


SMITH'S  SCHEME  FOR  CLASSIFYING  HUMAN-COMPUTER 
INTERACTION  INFORMATION* 


1.0  DIALOGUE  TYPE 

1.1  Question  and  Answer 

1.2  Form  Filling 

1.3  Menu  Selection 

1.4  Function  Keys 

1.5  Command  Language 

1.6  Query  Language 

1.7  Natural  Language 

1.8  Graphic  Interaction 

2.0  DATA  ENTRY/INPUT 

2.1  Position  Designation 

2.2  Direction  Designation 

2.3  Data  Type 

2.4  Entry  Formats 

2.5  Data  Validation 

2.6  Data  Processing 

3.0  DATA  DISPLAY/OUTPUT 

3.1  Data  Type 

3.2  Data  Density 

3.3  Data  Aggregation 

3.4  Data  Coding 

3.5  Display  Partitioning 

3.6  Display  Selection 

3.7  Data  Coverage 

3.8  Display  Update 

3.9  Data  Selection 


4.0  SEQUENCE  CONTROL 

4.1  Transaction  Selection 

4.2  Interrupt 

4.3  Context  Definition 

4.4  Error  Management 

4.5  Alarms 

5.0  USER  GUIDANCE 

5.1  Status  Information 

5.2  Routine  Feedback 

5.3  Error  Feedback 

5.4  Instructional  Aids 

6.0  DATA  TRANSMISSION/ 
COMMUNICATION 

6.1  Data  Transfer 

6.2  Data  Type 

6.3  Transmission  Control 


•Table  derived  from  Smith  (1980). 
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Table  D-6 

SMITH’S  SCHEME  FOR  CLASSIFYING  DIALOGUE  TYPES* 


Dialogue  Type 

Required 

User  Training 

System 

Response  Time 

Question  and  Answer 

Little/None 

Moderate 

Form  Filling 

Moderate/Little 

Slow 

Menu  Selection 

Little/None 

Very  Fast 

Function  Keys  with 

Command  Language 

High/Moderate 

Fast 

User-Initiated  Command 
Language 

High 

Fast 

Query  Languages 

High/Moderate 

Moderate 

Natural-Language  Dialogues 

Moderate 

(potentially  little) 

Fast 

Interactive  Graphics 

High 

Very  Fast 

♦Table  taken  from  Smith  (1980) 


dialogue  formats  for  the  types  of  uninitiated  users  who  will 
use  the  SDT  (response  time  is  not  a  critical  issue  for  the 
SDT ) . 

•  Data  Entry/input 

In  discussing  data  entry/ input  topics,  Smith  mentions  some 
general  guidelines  that  should  be  considered  in  the 
construction  of  data  entry  mechanisms.4  First,  an  operator 
should  seldom  be  required  to  enter  the  same  data  twice  or 
enter  a  data  item  already  entered  by  another  operator.  He 
suggests  that  the  way  to  do  this  is  to  program  the  computer 
to  maintain  context  (that  is,  the  computer  should  be  able  to 
access  all  data  related  to  the  user's  input).  Second, 
computer  systems  should  be  flexible.  This  means  that  the 
user  should  be  able  to  set  his  own  pace,  cancel  incomplete 
transactions,  order  inputs  including  temporary  omission  of 
unknown  items,  etc. 

e  Data  Display/Output 

Much  of  the  material  covered  in  Smith's  discussion  on 
display/output  is  redundant  with  Ramsey  and  Atwood's  work. 
Hence,  it  is  not  repeated  here. 

e  Sequence  Control 

Smith  suggests  that  menu  selection  might  be  used  as  an 
effective  means  of  providing  sequence  control  for 


4  He  also  has  an  appendix  of  more  specific  guidelines  which 
merit  careful  consideration. 
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uninitiated  users.  He  also  indicates  that  flexibility  is 
important  in  sequence  control,  particularly  in  interactions 
which  involve  the  modification  of  stored  data. 

•  User  Guidance 

Smith  suggests  that  the  fundamental  rule  in  the  area  of  user 
guidance  is  that  for  every  action  by  the  user  there  should 
be  a  response  by  the  machine.  Such  feedback  helps  maintain 
user  orientation. 

D.2.4  Sidorsky  and  Parrish  Work  on  Battlefield  Automated 
Systems 

A  comprehensive  assessment  of  human-con- outer  interaction  is 
currently  being  developed  by  Sidorsky  and  Parrish  (1980)  in 
work  conducted  for  the  Army  Research  Institute.  The  goal  of 
the  Sidorsky  and  Parrish  work  is  to  develop  general 
guidelines  for  describing  and  designing  battlefield 
automated  systems  so  that  ultimately  the  interoperability  of 
such  systems  can  be  increased,  and,  consequently,  user 
errors  can  be  decreased.  Like  Smith  (1979)  and  Ramsey  and 
Atwood,  Sidorsky  and  Parrish  (1980)  have  developed  a 
conceptual  scheme  for  classifying  information  related  to 
human- computer  interactions  (see  Table  D-7 ) .  They  have  also 
developed  a  method  for  systematically  assessing  the  human- 
computer  transactions  which  currently  occur  in  battlefield 
systems. 

The  study  by  Sidorsky  and  Parrish  was  only  begun  recently, 
hence  they  have  only  developed  guidelines  in  a  few  selected 
areas  (e.g.#  data  entry).  Thus,  their  work  provides  little 
current  guidance  for  the  SOT  development.  However,  Sidorsky 
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Table  D-7 

SIDORSKY’S  AND  PARRISH'S  SCHEME  FOR 
CLASSIFYING  HUMAN-COMPUTER  INTERACTION  INFORMATION* 


1. 

CONTROL  METHODS 

5. 

DATA  RETRIEVAL  ASSISTANCE 

1.1 

Command  Languages 

5.1 

Query  Method 

1.2 

Menus 

5.2 

Query  Structure 

1.3 

Function  Keys 

1.4 

Hybrid  Methods 

6. 

GLOSSARIES 

1.5 

Prompt/HELP 

6.1 

Standard  Terms 

6.2 

Character  Sets  and  Labels 

2. 

DISPLAY  FORMAT 

6.3 

Glossary  Availability  and  Use 

2.1 

Fixed  Alphanumeric  Displays 

6.4 

Abbreviation  and  Coding 

2.2 

Variable-Length  Alphanumeric 

Displays 

7. 

ERROR  HANDLING 

2.3 

Graphic  Displays 

7.1 

Prevention 

2.4 

Highlighting 

7.2 

Detection 

7.3 

Feedback 

3. 

DATA  ENTRY  ASSISTANCE 

7.4 

Correction/  Recovery 

3.1 

Information  on  Legal  Entries 

3.2 

Unburdening  of  Input 

8. 

USER/OPERATOR  CONFIGURATIONS 

3.3 

Interrupts  and  Work  Recovery 

8.1 

Opera tor(s)  Only 

8.2 

Operator(s)  and  User(s) 

4. 

MESSAGE  COMPOSITION  AIDS 

8.3 

Combined  Operator/User 

4.1 

System  Design  Features 

8.4 

Operator  and  User  Chains 

4.2 

Format  for  Alphanumeric 

Messages 

4.3 

Graphic  Messages 

♦Tabic  derived  from  Sidorsky  and  Parrish  (1980). 
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and  Parrish's  work  will  be  closely  monitored  as  the  SDT  is 
developed  since  it  focusses  directly  on  Army  systems,  and 
relevant  guidelines  developed  in  this  study  will  be 
incorporated  into  the  SDT. 

One  of  the  more  developed  areas  of  Sidorsky  and  Parrish 
which  is  relevant  to  the  SDT  work  is  the  identification  of 
techniques  for  highlighting  (or  coding)  information  on 
display  terminals.  Table  D-8  lists  the  highlighting  methods 
identified  by  Sidorsky  and  Parrish  and  indicates  which  of 
these  highlighting  methods  is  likely  to  be  appropriate  for 
the  SDT  given  the  general  restriction  that  the  SDT 
highlighting  techniques  must  be  applicable  to  a  wide  range 
of  existing  terminals. 

D. 3  SUMMARY  OF  IMPLICATIONS  FOR  SDT 

Reviewing  the  literature  related  to  man-computer 
interactions,  it  is  possible  to  identify  four  general 
guidelines  for  the  construction  of  the  SDT. 

First,  in  selecting  the  type  of  dialogue  which  is 
appropriate  for  the  SDT,  it  is  clear  that  some  form  of 
computer-initiated  dialogue  should  be  utilized  given  the 
types  of  uninitiated  users  who  can  be  expected  to  employ  the 
SDT.  More  specifically,  it  would  appear  that  three  dialogue 
types  —  question  and  answer,  form-filling  and  menu 
selection  seem  most  appropriate  for  the  SDT.  A  fourth  type 
of  dialogue,  query  languages,  might  be  selectively  used  by 
the  SDT  data  base  maintainers  and  other  more  sophisticated 
users  but  probably  is  not  adequate  for  general  use. 
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Table  D-8 

SIDORSKY’S  AND  PARRISH’S  SCHEME  FOR  HIGHLIGHTING  INFORMATION 


Brightness  Control 

Character  Size  Control  x 

All  Upper  Case  x 

Reverse  Display 

Underlining  x 

Different  Font 
Color  Control 
Blinking,  Pulsating 


Boxing  x 

Arrowing  x 

Symbolic  Tagging  x 

Alphanumeric  Tagging  x 

Position  Displacement  x 
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Second,  because  most  of  the  users  of  the  SOT  are  not  likely 
to  have  the  resources  to  purchase  ETES-speci f ic  equipment, 
the  SDT  must  be  compatible  with  the  input  and  output  devices 
which  are  currently  available  in  the  organizations  which 
will  utilize  the  SDT.  This  means  that  the  SDT  interactive 
input  device  probably  must  be  restricted  to  a  keyboard  (via 
existing  terminals)  and  the  SDT  output  devices  must  be 
restricted  to  printers  and  display  terminals  which  are  also 
available  on  these  terminals. 

Third,  coding  of  information  on  the  SDT  displays  should  be 
developed  in  accordance  with  the  most  current  guidelines  in 
Smith  (1979),  Sidorsky  and  Parrish  (1980),  and  Ramsey  and 
Atwood  (1980).  However,  any  coding  schemes  which  are 
developed  must  be  general  enough  to  apply  to  a  wi  !e  range  of 
terminals.  This  would  restrict  coiling  to  a  small  number  of 
available  techniques  (i.e.,  underlining,  italics,  character 
size  control,  position  displacement,  alphanumeric  tagging, 
symbolic  tagging,  and  arrowing). 

Fourth,  it  is  recommended  that  the  SDT  study  team  continue 
to  review  the  three  on-going  efforts  of  Smith,  Sidorsky  and 
Parrish,  and  Ramsey  and  Atwood  so  that  newly  developed 
guidelines  can  be  incorporated  into  the  SDT  whenever  it  is 
possible  to  do  so. 


